Workflow SYSTEM-GENERICINSTANTIATE not setting workflow container

[vapor_anomaly]

Hi,

Can someone please help me identify the cause of the below problem.

Sorry about the looooong post.

• We have a workflow
• One of the steps inside this workflow takes a key value and tries to create an object instance using the key value (Using BOR Method SYSTEM-GENERICINSTANTIATE)
• This step seems to create the object reference successfully, but it does not seem to assign it back to the export parameter (workflow container element) (See Screenshot 1)
• Because of this, the subsequent steps which are attempting to use the object reference are failing (See Screenshot 5)

Below are some observations

• The object reference were are trying to create is of type ZISUIDESWD (Custom BOR Object)
• The type of the workflow container element is ISUIDESWD (Standard BOR Object)
• There are three different points of trigger for this workflow (From existing process for which we do not know the origins of, from a custom report 1 using FM SWW_WI_START_SIMPLE, from custom report 2 using FM SWW_WI_START_SIMPLE )
• The workflow step in question works fine when triggered by existing process and from report 1 (See Screenshot 4)
• The error occurs only when workflow is triggered from report 2 (See Screenshot 2)

What have i attempted so far

• Tried executing report 2 in background (In actual production system, this will not be executed in background. But i just tried to be sure)
• When calling FM SWW_WI_START_SIMPLE, I passed in CREATOR = WF-BATCH/USWF-BATCH & CALLED_IN_BACKGROUND = 'X'
• Filled in the workflow container element and passed it into the FM SWW_WI_START_SIMPLE (See Screenshot 3)
• I have checked and compared the code in report 2 Vs report 1, there are no differences in the logic for workflow triggering

Screenshot 1: [Showing that the step/task/BOR Method itself has executed successfully. As can be seen by presence of valid value in the element 'ObjectInstance']

Screenshot 2: [Showing the error message in the step log. Please note that the last two nodes of error message is from the subsequent workflow step, which uses the container element, which was supposed to be filled by this step]

Screenshot 3: [Showing that at the main workflow level, the container element SwitchDocument is filled because i passed it in container, when triggering the workflow. Please note that when i do not pass it container, this element stays empty even after execution of GENERICINSTANTIATE]

Screenshot 4: [Showing that the exact same step works fine and workflow progresses when the workflow is triggered from other report]

Screenshot 5: [The Green circled step is the one which is supposed to created the object instance and assign to workflow container. It is shown in 'Completed' status, despite the error log being populated (Screenshot 2). The Red circled step does not appear in the workflow log. But it attempts to use the object instance. The last 2 nodes of Screenshot 2 refers to this step]

Thanks,

Tala.

[Clucking]

Not exactly an answer - but if object ZISUIDESWD just implement custom elements to ISUIDESWD you should consider doing a delegation between the two objects instead and then only have an object of the type ISUIDESWD in your workflow - and then get rid of the step.

[vapor_anomaly]

Understood.

I am still trying to find out how it works when the same workflow is triggered from the two other points and error occurs only when my new code triggers it.