Is this piece of Catalog workflow we have two possible outcomes. The first (long route) will create a Change Request and an Incident and the second (short route) will create just a Work Order. As you can see, we control the flow by using a number of exclusive gateways. In this example the users initial question response will determine the actual path. From the Remedy ITSM side the status of each fulfillment application is routed back by a combination of Remedy workflow and integration JAR file which is triggered by the remoteaction.bat file on the host of the AR Server.
The Catalog Remedy workflow & JAR file (along with the manager approval chain) is implemented by the Catalog ITSM integration patch which is available on our EPD site.
We use "Receive Task" here to listen for the fulfillment status and continue the flow (if required).
If the status isn't being sent back to the DWP Client, check the remoteaction.log and the SB:ServiceRequestStub form for errors on the AR Server.
To begin with, we create a number of input variables which will be used to map question responses to fields within each application. Another question is added here for workflow direction.
As you can see, the flow will only proceed on the branch defined if the highlighted condition is met. If any other answer is provided it will choose the other path.
Now that we've completed our design, we can start mapping our question responses in addition to manually setting all of other required fields. For the purposes of this example I'm only mapping the summary however we can of course create separate questions to map against all of the other fields ( just make sure to select the correct question type).
Don't forget to use the service Broker context variable for common fields !
We also need to set our Process Correlation ID to associate the request with the relevant fulfillment application in ITSM.
Once our Change request has completed, we need to add "Get Change Request by Identifiers" to collect it's identity.
To keep the end user (DWP Client) informed of what's going on we're using the CRQ ID from above to pass back to the request along with a custom message.
Remember, the status values need to match up to those defined in the enumeration table of our documentation (Setting the service request status).
Now that the status has been mapped to the request, we use "Receive Task" to stop the workflow and wait for a signal from the Change Request.
On the other side of the branch, our exclusive gateway will only allow an Incident to be created once the status (completed) has been received.
Once again, we need to collect information about our generated Incident for use in subsequent activities.
Just like the Change Request, here we're feeding back the status and another custom message along with the actual number of the generated incident.
We can leave the receive task parameter name as it is and use it for the same purpose as our Change Request.
Once the Incident has been "Resolved", we close the request in the Digital Workplace client and pass our custom message.
You could also use the actual Incident status reason for resolution from "Get Incident By Identifiers" here.
Finally, let's add our input questions and tie it all together. As you can see, I've added simple conditional questions to map the summary depending on the flow route.
Now let's submit the request choosing the "Long route" to generate our Change Request and Incident !
As you can see, the fulfillment activity has been mapped for each step of the way !
In summary, with just a few simple workflow actions we have provided a dynamic view of fulfillment application activity !
That's all for now but I'll be back with more workflow Blogs soon...
Happy new year to all !