Hello All,
I am trying to determine if active workflow variable data is stored either in xml or in the database while a workflow is being processed in IIQ. For example, if we have a long running workflow, is it possible for us to review the variable data in the workflow without having to use a logger. In other workflow products, we can review the payload to determine issues etc… We can track the workflow, stages and results but have not found a way to track the variables without logging.
Active running workflows are represented in XML format as WorkflowCase objects which can be viewed via the debug pages.
These objects are useful because not only does it give you current values for variables as the workflow progresses, but it also lets you know which workflow step is currently being processed, even if it’s a step within a nested workflow.
Just keep in mind that these objects do not persist after the workflow has completed. So in the case of a long running workflow you should be just fine, but if you’re troubleshooting a workflow that runs for just a few seconds, you can add a wait argument to a given workflow step to force it to persist temporarily.
Here’s some general (albeit old) workflow documentation that may be of additional help - LINK
Thank you for the quick response. I have a wait statement for 10 minutes in one of my test workflows; however, I am not seeing the workflow case when looking under debug. The workflow is launched from the rest API using postman and does complete successfully. I will review the documentation that you sent as well for other clues.
Hmm. Even if the workflow is marked as transient, a WorkflowCase should still be generated by the wait step.
I’ve attached a sample workflow for you to try - I’ve tested and confirmed in my 8.1p2 environment that if you execute it from IIQ’s Rest API it generates a WorkflowCase. The workflow itself creates a custom object (serves as a log) to capture the name of the WorkflowCase object it creates, so you can reference it later and use it to search for the object while the wait step is running.
Give this a shot and let me know if you still don’t see a WorkflowCase object. If you do see one with this test, then we may need to take a closer look at the workflow itself to understand what exactly is preventing the creation of a WorkflowCase.
That worked. I see the workflow case and the variables that I sent into the flow. Not sure why I am not seeing the workflow case on my flow. My flow is a copy of the password intercept workflow for password provisioning downstream. I will create a clean workflow that does the same thing and see if that fixes the problem.