5 Replies Latest reply on Apr 14, 2020 1:05 PM by Ezra Wise

    'Receive Task' not working after 'Track External Activity'

    Ezra Wise
      Share This:

      Hello,

       

      I have a workflow that uses a 'Create Entry' instead of a 'Create Incident' widget in the Remedy Connector.  I have been able to update Work Notes and Comments bi-directionally by adding the 'Track External Activity' per the following discussion:'Create Entry' and interaction with SB:ServiceRequestStub

       

      However, My 'Receive Task' is never triggered successfully.  I have updated the SB:ServiceRequestStub record and it looks like the "remoteaction.bat" is being invoked successfully.  I see the following excerpt in the bundle.log:

       

      Caused by: com.bmc.arsys.server.rx.services.RxFrameworkException: [ERROR (909): The process does not exist on the server.; Process Definition Name: <myit-sb:Standard IT Request> process Instance ID: <IDGAAEHXAAW4NAQILCF7QILCF71F2K>]

       

      Note: the process Instance ID <IDGAAEHXAAW4NAQILCF7QILCF71F2K> appears to be part of the process correlation id set in the stub record, which is:

      'Process Correlation Id' = "rx-7b438031-fc9c-499c-ad9f-74fdbd0a6382|IDGAAEHXAAW4NAQILCF7QILCF71F2K||IDGAAEHXAAW4NAQILCF7QILCF71F2K"

      ...so I'm assuming that is where it is getting that information.  I don't know where to check on the Catalog side to confirm that the process Instance ID is correct.

       

      So it never gets past the 'Receive Task' step - presumably because it never is aware that a response has been provided given the error above.  I'm pretty sure the SB Stub record in ITSM is correct and the 'Receive Task' and 'Track External Activity' steps are configured correctly, although I would be happy to provide additional screenshots for confirmation.  I've provided the excerpt of the workflow currently tripping me up:

       

      I tried several different permutations of the above, including looping back to the receive task (and not the 'track incident' step), removing the receive task step altogether (which caused the workflow to loop wildly out of control because I'm still not 100% sure how the 'Track External Activity' step works), and adding a 'Track External Activity' both before the receive task loop and within it.  Nothing has worked and I see the same error as indicated above each time it gets to the 'Receive Task' step.

       

      Any help is greatly appreciated.

        • 1. Re: 'Receive Task' not working after 'Track External Activity'
          Paul Seager-Smith

          Hi Ezra, the Receive task works for me. Few things to check:

          1. Which version of DWP-A are you using?
          2. I don't see your update to the stub form entry - where is this done? Probably not relevant to the receive task issue, but I do it after the track activity.
          3. Do you use a sub-process or call activity - each process has its own process correlation id and so if the create entry and receive task are in different processes, the wrong id will be used if you don't explicitly set the correct id?
          4. Do you provide the process correlation id when you call the create entry? I think it takes the id of the current process by default, but this would make sure. It is also worth have a debug statement (send in app notification or create activity log) to display the process correlation id, so you can check it against the stub form entry.
          • 2. Re: 'Receive Task' not working after 'Track External Activity'
            Ezra Wise

            Thanks, Paul Seager-Smith.  Here are some responses:

             

            1. Which version of DWP-A are you using?  19.11
            2. I don't see your update to the stub form entry - where is this done? Probably not relevant to the receive task issue, but I do it after the track activity.  I originally had it placed prior to the update stub workflow, but moved it during troubleshooting to make it more representative of some of the examples I saw in some other of John Gallagher's posts.  I've provided the full workflow below.
            3. Do you use a sub-process or call activity - each process has its own process correlation id and so if the create entry and receive task are in different processes, the wrong id will be used if you don't explicitly set the correct id?   No.  (At least, not that I'm aware of)
            4. Do you provide the process correlation id when you call the create entry? I think it takes the id of the current process by default, but this would make sure. It is also worth have a debug statement (send in app notification or create activity log) to display the process correlation id, so you can check it against the stub form entry.  Yes.  I explicitly set it to General > Process Correlation ID.

             

            Here is the full workflow with an example of what I am seeing when creating the service request:

             

             

            Create Entry step:

             

            Track External Activity step details:

             

            When submitting the SR, here is the stub record that is generated and updated by the workflow:

             

            Here is the output from my 2 debug messages:

            msg.png

             

            When I update the Incident Status, the stub record is updated and "Sent"

            stub_update1.png

             

            And it appears that the payload is correct:

             

             

            But here is the excerpt from the bundle.log showing the track activity being called, but then the 909 error:

             

            04-12 05:59:05.531 INFO [ActivityLogSrvImpl][bg script][wisee1>Remedy Application Service@duvalschools.org] OpId: none External Activity 10206 created. Checking to see if any Activity Log needs to be sent

            04-12 05:59:05.545 INFO [ActivityLogSrvImpl][bg script][wisee1>Remedy Application Service@duvalschools.org] OpId: none Getting all Activity Logs with broadcast as True and broadcast status as NotSent

            04-12 05:59:05.547 INFO [ActivityLogSrvImpl][bg script][wisee1>Remedy Application Service@duvalschools.org] OpId: none Found 0 activity Logs

            04-12 05:59:05.560 WARN [ServiceRequestSrvImpl][bg script][wisee1>Remedy Application Service@duvalschools.org] OpId: 074efc8a-e68f-4eb3-bfde-b10488 ignoring failure to retrieve process instance "myit-sb:Standard IT Request/IDGAAEHXAAW4NAQIOG46QIOG4628HY" for service request 10206 during fulfillment phase: {}

            com.bmc.myservice.common.util.exception.MyServiceException: [ERROR (909): The process does not exist on the server.; Process Definition Name: <myit-sb:Standard IT Request> process Instance ID: <IDGAAEHXAAW4NAQIOG46QIOG4628HY>]

             

            I'm assuming that the ERROR (909) is a result of running into the Receive Task step in the workflow, but I'm not positive.

             

            Thank you for taking the time to look at this.

            • 3. Re: 'Receive Task' not working after 'Track External Activity'
              Ezra Wise

              I created a new Service Request and workflow for testing.  The receive task works correctly now.  I did change the order of the 'Track External Activity' to come before setting the SB:ServiceRequestStub record, which comes before the Receive Task.  I will play around with the order of my original workflow to see if I can get it to work.  Otherwise I'll just re-create my entire workflow anew and hope that this was a one-off instance of data corruption (or something).  I will provide another update once complete.  Thanks again for the help!

              • 4. Re: 'Receive Task' not working after 'Track External Activity'
                Ezra Wise

                I may have "lucked into" an answer.  The last thing I did when re-creating the workflow was to add a 'Create Activity Log for Service Request' step just prior to the 'Receive Task' step.  After that the receive task no longer worked and I received the same error (909) as mentioned above.  Removing the 'Create Activity Log for Service Request' step (and its 2 predecessors, 'Get Incident By Identifiers' and 'Get Entry' to look up assigned group information to put into the Activity Log update) the workflow again works as expected.

                 

                So, it's the inclusion of one of the following that is causing the issue:

                1. Get Incident By Identifiers

                2. Get Entry (I doubt it's this one since I'm using it elsewhere in the workflow already)

                3. 'Create Activity Log for Service Request' ( <-- My money is on this one)

                 

                I've raised a case with BMC Support to see what they find out.  Maybe a bug/defect?

                • 5. Re: 'Receive Task' not working after 'Track External Activity'
                  Ezra Wise

                  Ok, this time I added each step in one-by-one to confirm which step was causing the issue.  It is the "Create Activity Log" step.  However, I also realized that if I included a valid "Author Login ID" value (an actual DWP Catalog user login id) the workflow and Receive Task worked as expected.  When I used an arbitrary string in this field the Receive Task (the remoteaction.bat script, actually) fails with the 909 error.  I used an arbitrary value to provide a "friendly display" to the Service Request activity log instead of a system user id.  Per the documentation, "You can add any value in quotes to this field." However, sticking to a valid login ID seems to be necessary to avoid unforeseen consequences.

                   

                  ...and it only took me nearly a week to figure it out