This content has been marked as final. Show 9 replies
Yes, we need to accept the task in the web client and then put in Received again to the task resume processing.
Just to detail a little more our process:
We have 2 automated tasks, A -> B. The first task sends a request to an external application and waits for the response. Then for some reason we need to suspend the order. After that we receive the response from the external application. OSM then completes the task A and go to task B. The task B stays in Receive status and the Order with state Suspended.
If then we resume the Order the Task B don´t resume processing. It stays forever in Received state.
I'm having similar issue...
In my case, during the process execution when we receive an backend system application error in a task with an external automator receiver we need to suspend all processes and the order in the context. After all metadata in the backendSystem being corrected we need to resume the order and redo the same task that failed. In our case we are not using amendments because the order wasn't changed.
The major issue we are having is when we resume the order, the processes with task stopped in "received" status, don't restart and we need manually to go the Task WebClient and change to status="accepted".
Is any solution where we could resume an order and the task that contains automator start automatically?
I understood from your both requirements thats you will suspend the order as per business needs and resuming once once that business needs fulfilled.
I have not worked on suspend and resume order webservice. But one suggestion i can give you to try out..
use automation context in automation task to accept the task, so that the task process will initiate.
TaskContext taskContext = (TaskContext) context;
Hope this helps. Pls post your findings.
When an order is resumed, any automated tasks which are in the received state should automatically resume processing. OSM does this by automatically looking for any automated tasks in "received" state and creates messages in the internal oms_events queue that initiate processing of those automated tasks which then put them into accepted state as those oms_events messages are processed.
If an automated task is already in accepted state when an order is suspended, OSM will wait for that automated task to complete in a "grace period" prior to the order being successfully transitioned to suspended state. The maximum amount of time OSM will wait for these in progress tasks to complete is defined by the grace period value provided when the suspend order task is performed.
Check your scenario based on the above description - make sure you test this with a simple cartridge first. If it's not working for you please contact Oracle Support and submit your test cartridge as a reproducible test case.
Vice President - OSM Architecture
Your explanation was very helpful. Thanks.
We have fixed the problem. It was a bad configuration in the OSM queues.
We have another question regarding Resume Tasks.
Lets image that we have an order in suspend state with some tasks in suspend state also. When we resume the order it is expected the tasks in suspend state to resume processing? There is any way to do it automatically or it has to be done manually?
The state of suspended tasks are not changed when a suspended order is resumed. This is because those tasks would have been placed in a suspended state prior to suspending the order very likely for reasons altogether separate from the reason why the order was suspended.
As to automating putting those tasks back to an accepted or received state, you could add an order lifecycle notification event handler for the order that responds to a suspended order being resumed. This automation plugin for the resume event could then use context.processxmlrequest to invoke the XML query API to find suspended tasks for the order in question and then use other xml API calls to change their states.