Workflow publication is one of the crown jewels of Duet Enterprise. It is applied to expose selected SAP workflow tasks in a task inbox on SharePoint, where users can next handle the task from their familiar office workplace. But what if upon task notification from SAP to SharePoint, the receiving SharePoint side is temporarily unavailable? For instance, due a planned or unplanned system reboot.
Well as it turns out, on the SAP sending side all the task notification requests are queued. And when a request cannot be successfully delivered, it is administrated in the SAP queue with error status that indicates the problem cause. You can manually resend the failed delivered task notifications from the queue.
The steps to that are the following:
- [Optional] Lookup the workitemid(s) of the task notifications that are not delivered. You can do this via diverse manners. One is to inspect SLG1 log for the logged output of S_WF_OSP_ITEM_SELECTION. Another is to analyse the workflow, e.g. via SWIA.
- Open transaction SBGRFCMON. If you know the workitemid(s), then search for queued units for this one, by entering “*<workitemid>*” for queue name. If you do not known the workitemid, then just perform a free search. Click Execute.
- Inspect the queue search result, and look for blocked queued units. In particular look for requests of ‘/IWTNG/WF_CREATE_TASK_PRX_ADP’ and ‘IWTNG/WF_EXIT_TASK_PRX_ADP’.
- For any of the found queued units, repeat the failed action. You do this by right click on the queued unit, in the menu navigate to submenu ‘Unit analysis’, and select ‘Run unit with runtime Analysis’, and execute the retry action.
- Return to the SBGRFCMON selection screen, repeat the search, and verify that the locked queued unit has now been removed.
Result:
On the SharePoint side the request is received and handled by the Duet Enterprise workflow functionality; for CREATE_TASK a new task will have been created in the SharePoint task inbox, for EXIT_TASK an existing SharePoint task will have been cancelled.
