Triggering a custom SAP ME workflow without having XSLT
Being a very newbie in the SAP ME doamin this is my first SCN blog on SAP ME. In one of my recent projects, we are planning to build a custom solution on top of SAP ME standard LOIPRO interface. So I started to explore the in-built functionality of SAPMEINT component and this blog is all about the findings related to SAP ME Workflow.
The SAPMEINT component has different workflow configurations to invoke ME web services for transfering SAP ECC data to shop floor. It also has another set of workflows using which SAP ME can send message to SAP ECC via BAPI call. SAP ME has an in-built project called “Visiprise” to maintain the workflow and message processing through SAP MII and being an in-built deployed project, no technical information is available in SAP help documentation related to this code base. So it was very challenging to develop any custom solution on top of the “Visiprise” project without knowing the internal transactional flows.
In my project one of the primary requirements was to send the error message to ECC user s in a popup window and we already have one custom BAPI to perform this functionality.Now to handle this BAPI call at any point of time we can always build a set of custom transactions in MII.
Instead of following the traditional approach, I wanted to design our solution in a different way and decided to build a brand new functionality which will have some custom workflow to execute the queued message purely in SAP ME fashion.
So I started looking for an option to trigger a custom SAP ME workflow which will process a non SAP ME message structure(custom message). After a bit of ground work, I took a simple BAPI called “BAPI_ALM_NOTIF_CREATE” and to get the input structure of the BAPI, I called this BAPI in non execution mode using “SAP JCo Interface “action block inside SAP MII workbench.
Once I got the request structure, I prepared the complete BAPI request with required input parameter values and additionally I put one root node (createAlarmNotification) and one child node (plant) to it as shown in the below message structure. Now my custom message is ready to be posted in the queue and the final message looks like :
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?>
Then to post the message I have used Visiprise/ERPShopFloorIntegration/services/SAPMEOutboundService BLS. It actually takes message as a form of document and internally calls Visiprise/ERPShopFloorIntegration/services/AsyncDOCService BLS to enqueue the message. Basically from my custom BLS I made a call to SAPMEOutboundService BLS to post the message in the integration message queue.
BLS AsyncDOCService enqueues the message using SAP ME “Enqueuer” action block. Enqueue action block inserts the message in the integration message queue i.e. SAPMEINT_MESSAGE_QUEUE data table of SAPMEINT data source as a “queued” message.
While posting the message, root node of the message is considered as the message type to distinguish the message from other messages. In the above example “createAlarmNotification” works as the message type.
Now to process this queued message one new standard workflow (standard workflow is required as MII needs to send this message to ECC) needs to be created in the SAPMEINT Workflow Configuration page (SAP ME ERP Integration -> SAPMEINT Configuration -> Workflow Configuration).
Fig: 1 Creating a standard workflow for a custom message
For the identifier of this workflow I have used the following parameters as “Workflow Handler Parameters” to follow the SAP ME internal plant specific design:
Fig: 2 Queued message in the queue monitor
To make a call to the BAPI I have used Visiprise/ERPShopFloorIntegration/frame/workflow/StdSAPBAPIHandler BLS as “service transaction” in the workflow configuration. As you can understand by the folder path (mentioned above) that the BLS is provided by SAP itself to handle different BAPI calls.
Along with the “service transaction” parameter another parameter called “Service Transaction Parameters” is also defined in the workflow configuration.
This parameter actually passes the BAPI name to the service transaction i.e. StdSAPBAPIHandler BLS to call the BAPI with the request message.
Fig: 3 Mapping Service transaction in the workflow
As this is a custom message and it’s not coming from the ME, no XSLT file needs to be created for this workflow.
To handle the response of the BAPI based on the success and failure, Pass Handler and Fail Handler BLS can defined respectively in the workflow. Here we can provide any kind of custom BLS to handle the post processing logic of the BAPI call.