Skip to Content

NOTE: If you are only interested in the temporary workaround, scroll down to One Small Problem

The wait (for event) step has been in the workflow designers toolkit for a long time.  It’s limitation is that the object that has the event for which the wait step is waiting must have an instance in the current workflow.  Thus, I can wait for BUS2012.significantlyChanged only if I have instantiated BUS2012 (Purchase Order).

But, what if I would like to listen for an object-event that has yet to happen and thus I cannot possible create an instance of it.  For example, for whatever reason, my workflow is started by creating a new purchase order, and there is a point in the process where I want to know that the purchased material has been received.  This would require business object MSEG.  Well, I can’t wait for an MSEG event in my workflow unless I have instantiated it and that object won’t be able to be created for day or weeks in the future.

What I need is someway to be notified when material has been received that references my purchase order.  This is the correlation.  This one capability provides the workflow analyst a powerful new tool to address all sorts of dependent events.  

Say a customer calls with a complaint about material he has received.  You create a complaint record.  You give the customer an RMA number and ask him to send the material back.  The workflow’s next stop is to someone to investigate the validity of the claim, but there is no sense sending it to that person until the material is received – a good place for a correlation wait step.

Perhaps you have a workflow that needs to know when a credit has been issued, or when a work order has been created in response to a quality inspection defect, etc.  What all of these have in common is that they can be linked to each other by one or more data elements known to both of them.  This is called anecdotal information.  MSEG holds the purchase order number on inbound goods receipts.

How-To

A correlation is a separate object you create using transaction SWF_CRL1.  You use it to define the target business object (the one you can’t instantiate in your workflow) and the data elements that are known to it and your base business object.  I had to extend object MKPF (delegated ZMKPF) and add a custom attribute PurchaseOrder because MSEG has the purchase order number, but no events, and the correlation needs an event from the target object. 

Next (in SWF_CRL1), you define the variables that will be used to link the two business objects.  It looks a lot like the way you do it in the workflow container. So define an element, PurchaseOrder (EKKO-EBELN).

By double-clicking on the business object (MKPF) you enable the binding editor which allows you to link MKPF.PurchaseOrder to PurchaseOrder.

When that is done and saved, you have your correlation and are ready to configure the correlation wait step.

Wait step

Under “Wait” select “Wait for Event” and check “Use Correlation” .

In the Wait for Event section:

Select BOR Object Type and enter MKPF (or whatever) and event ASSIGNED (or whatever).

Next, the binding editor.  IMPORTANT: the first binding editor has not effect on the correlation itself.  It is there merely to pass the event object to a receiver in the workflow container so that you can use that instance elsewhere in the workflow.  I created a reference to MKPF in my workflow container and executed the binding.

Next, you enter the name of the correlation object you created; e.g. ZCRL_PO_GDS_REC.

Below that you can select the method of comparison: Using Binding or Using Base Element.  Select Using Binding.  

In the second binding editor link the purchase order number to the PurchaseOrder element you defined in the correlation: e.g. oPurchaseOrder.PurchaseOrder -> PurchaseOrder.  That is where the connection of the shared data takes place.

The correlation wait step is now complete.

One Small Problem

There is currently an OSS Note 1335009 that has not yet been released that addresses a problem with the correlation wait step.  That is, the wait step will not instantiate because of a missing binding that should take place automatically.  Without doing the following, the wait step will always error out until the OSS Note has been applied.

Assumption: you have configured the wait step as described and have saved the workflow template.

Now:

1.  Open the wait step and de-selected the “Use Correlation” checkbox. The format changes.

2.  Using the F4 key, select the the local definition of the target object (oMKPF or whatever) for the Container Element value.  You WILL need to define this even though you may not use it in binding #1.  This is the binding that should occur automatically.

3.  Click Save and then RE-check the “Use Correlation” checkbox.  Save and activate the workflow template and you’re good to go.  

That all you need to do.  I hope you’ll experiment with the workflow feature.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply