Category Archives: SAP

Is Duet Enterprise Workflow the weakest link?

Duet Enterprise FP1, as great as it sounds, forms a glue between Microsoft and SAP. This blog post talks about how Duet Enterprise workflow may be the weakest link of features that comes with Duet Enterprise.

In a nutshell, workflow in Duet Enterprise is implemented as two-way communication between SharePoint and SAP Netweaver Gateway. End users in SharePoint see workflow tasks with action buttons, nothing different from the way they would approve or reject a sharepoint workflow task, because it is a sharepoint workflow task. All great and good, but under the covers, implementation is not as elegant as it look.

Workflows in Duet Enterprise are exposed per user-decision interaction step, more simply, this is the diamond shapes in a workflow sketch. At its plain configuration, each one of this interaction step is mapped as a subsite which hosts workflow task for this ‘type’ in SharePoint side. Yes, one step – one subsite.

Workflow mapping

Source: Plan for SAP workflow tasks for Duet Enterprise

This would mean that administrators and developers would need to maintain a list of user decision points which has been exposed. For SAP, it means at any time when any of these decision points change, they may need to reconfigure workflow pattern customizations and/or filters. Then all changes would need to be captured and documented clearly and handed over to SharePoint administrators and/or developers.

On the SharePoint side, Microsoft seems to be missing a few core operations that make this maintenance even harder. A workflow task type is configured in SharePoint by specifying task type and outcomes as they appear in SAP. For example, task of type CampaignApproval has been configured with outcomes Approve=001 and Reject=002.

When the scenario where additional outcome has been configured on SAP side (eg. Revision Required=003), this CampaignApproval subsite has to be reconfigured in SharePoint, which is fair. Question is, how?

1. Deleting the workflow subsite will not work, because then the workflow parent site still thinks that the workflow type is still configured and render the task not usable, and we won’t be able to create a task with the same name either.

2. Changing the outcomes in sharepoint designer and republish workflow might work, but really?

There are few options provided in the site actions menu, but it looks like when one is configured, there is no way of reversing it, modifying it and clean it up properly without destroying the whole site altogether.

Workflow config options

I am puzzled indeed. May look into doing it programmatically next, but certainly Microsoft, I wonder if this has been thought through?

%d bloggers like this: