Skip to Content

I would like to share an interesting issue I encountered with UWL.

After opening a HCM Process and Form adobe form from UWL work item , my internet explorer crashed with an error. I opened the work item again and received a message stating that the work item was locked by my ID.  There were no entries in SM12 for my user ID.

Thinking that the work item will be unlocked once I log off, I logged of from portal and logged in again and was surprised to see same error. SWI1 showed status of this dialog work item as “Started”.

Next option that I tried was to resubmit the work item from UWL which did not resolve the problem as I was asked to select a future date to resubmit the work item and even after specifying the future date, the work item was still in the status Started. Forwarding the work item to other user as admin was not a good option as work item already in “Started” status would have returned same error to the user who received forwarded work item.

When I tried Replace Manually option from SWIA, it changed the work item status back to READY resolving the issue. 🙂

Image 1.jpg

However I am still unable to understand after crash of the web browser when I logged in again, shouldn’t system allow me to relaunch the work item again from UWL? Even if the status was Started, the option to resubmit the work item from my UWL should force work item back to ready status.   😕

From end user perspective it would not be very intuitive and faster solution to drop a note to workflow admin in case of browser crash. 

Would like to hear more from others on possible solutions or any steps that I have missed and it would surely be a good learning for me. 🙂

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Jocelyn Dart

    Hi

    Ok well I can help clarify a couple if things.

    Firstly resubmission is a delay tactic to hide workitems until a date when you are ready to deal with them. I regard this as confusing and often bad business practice and we nearly always turn this off on sites.  Resubmission has nothing to do with restarting or resuming a particular work item.

    What you should have seen in the preview area of your work item is the Cancel Assignment option which is what the replace manually option is called in the UWL (btw reserve is called Assign to Me).

    Also when you launch a workitem it has no connection with the launched application unless it responds in a workflow-appropriate manner such as by raising a workflow event that the workitem or its parent workflow recognizes. So the UWL would be unaware of the failure – as far as it is knows you are still executing the launched application. 

    Regardless congratulations because you did find the best/easiest answer to such problems which is to let the workitem/workflow know the status has changed  – however next time perhaps watch out for the assign to me/cancel assignment  buttons.  Btw forward would probably have worked also because reassigning the work to another agent also tells the workflow something has changed. Which is really all it needs to know to let you continue

    Hope that helps

    Jocelyn

    (0) 
  2. Jocelyn Dart

    Hi

    Ok well I can help clarify a couple if things.

    Firstly resubmission is a delay tactic to hide workitems until a date when you are ready to deal with them. I regard this as confusing and often bad business practice and we nearly always turn this off on sites.  Resubmission has nothing to do with restarting or resuming a particular work item.

    What you should have seen in the preview area of your work item is the Cancel Assignment option which is what the replace manually option is called in the UWL (btw reserve is called Assign to Me).

    Also when you launch a workitem it has no connection with the launched application unless it responds in a workflow-appropriate manner such as by raising a workflow event that the workitem or its parent workflow recognizes. So the UWL would be unaware of the failure – as far as it is knows you are still executing the launched application. 

    Regardless congratulations because you did find the best/easiest answer to such problems which is to let the workitem/workflow know the status has changed  – however next time perhaps watch out for the assign to me/cancel assignment  buttons.  Btw forward would probably have worked also because reassigning the work to another agent also tells the workflow something has changed. Which is really all it needs to know to let you continue

    Hope that helps

    Jocelyn

    (0) 
    1. Parag Parikh Post author

      Thanks Jocelyn for the explanation, tips and correcting me. I will use Cancel Assignment button next time ( if browser crashes again 🙂 ).

      I tried forward option last time but it did not work. Work item was forwarded from “User1” to “User2”. But when I tried executing work item as User2, I received message that the work item is locked by User1.

      I agree to your point that “the UWL would be unaware of the failure – as far as it knows you are still executing the launched application.”


      As you explained “Assign to me” will reserve work item for user with status “In progress” in UWL and “Cancel Assignment” would mark work item once again in status “New” in UWL, which is same as “Replace Manually” in SWIA.

      Irrespective of the option we chose i.e. use Cancel Assignment or SWIA “Replace Manually”, both does not sound very intuitive for the end user as why would someone think in the direction that he needs to Cancel Assignment of the work item which he has already started executing after a web browser crash? 🙁 However I definitely agree with you that “Cancel Assignment” would be a better option as user can resume his work himself using this option without reaching out to workflow admin.

      I also agree that resubmission as a delay tactic is a bad business practice and end users should not be encouraged to use it or it should be disabled. Thanks for the tip.

      (0) 
      1. Jocelyn Dart

        Glad it helped.  Of course one would hope that a web browser crash would be very rare… but maybe something to throw into a FAQ document linked to the same portal page as your UWL? Just a thought.

        (0) 
  3. Sameer Tapre

    I have worked on HCMP&F few years back and as I remember this locking error message is because of a lock placed in the shared memory object.

    The shared memory object has some lifespan of 2-5 mins (Don’t remember exactly). In case the web page crashes the lock is released after the default lifespan of the object.

    (0) 

Leave a Reply