Simple bi-directional integration between Windchill - ERP (ERP Connector-Closed Loop)

Well my customer came to me one busy day and he asked me question, is it possible to accomplish a bi-directional integration between Windchill and ERP without too much of customization and investing in 3rd party tool's/solutions and he wants to see the following in the proposed solution:

• When new material (Part) created in Windchill should be published (either through change notice {RTM} or direct Distribute to Target action ) to SAP and it should update successfully in SAP.
• If its existing part then only changes should update in SAP.
• The cost information added/updated in SAP should update in the material (Part) attribute before the release.
• If any issues or data inconstancy or other Inventory related issue, the publishing must be fail (roll back to unpublished state, re-initiate).

As he was saying, my mind was flipping through many solution that I was aware of and implemented in the past like:

• SAP Publish Using Jco & ERP Connector (Gururaj Kanjan). Using SAP Jco one can call BAPI functions (SAP have to be enabled for remote execution) from java.
• Publishing into intermediate table (Database either in Windchill or SAP) and running scheduler in SAP which will read the data and update the SAP and update table back with success or failure - this method is not reliable solution thou...
• File based solution but again not sure how to achieve closed loop as we have watch for the file modification etc... to realize the transaction is success/failure.
• And also gave thought to publish the response to the message Queue stream (SumMQ/RabitMQ) and wait for the response to update the transaction.

The next day I was preparing the POC considering different options, he came to me and said he forgot to mention that the transaction should be real-time and there will be workflow runs in the SAP which will update the cost, manufacture's etc... of the new materials upon completion (this workflow process may take considerable time some time days). what he meant was the windchill publishing should be suspended until the SAP response and should activate only upon response and should update Windchill accordingly.

Then i realized that the solution I was proposing in the POC's may not be feasible. And that because the most challenging part here was how to manage (add or update) the SAP driven attributes like cost, manufacturer, AVM/L etc..., how long to wait for the SAP workflow to complete to initiate the Windchill update process? so on...

After scratching my head for a while, I thought and came up with a solution of integration through web-services! and below is the concept diagram:

The basic idea of this solution is to unitize the web-service capabilities of both application and call each other when are ready to do so. This solution basically leveraged with supported API from both end and also not required to implement any middle-ware, adapter etc.. which may required to write Listeners and schedulers to listen and act periodically.

Okay now lets look at each of them how it works:

Lets first understand Windchill ERP Connector Architecture, as you can see the last part of the RTM is ESIResultEvent which is key to our solution.

Before we go further we need to understand how the RTM works (I will not go all parts of it - more details in customization guide),

When the user releases an object from Windchill PDMLink, the RTM workflow that gets launched performs pre-release validation and then invokes the release() method of StandardESIService. 

This method creates an instance of wt.session.SessionThread that wraps around an ESIResponseGenerator instance. One of the attributes on ESIResponseGenerator is a handle to the ESIRelease object – this is either a newly created object (when releasing the object for the first time), or one that is already associated to the primary business object in the release (when resubmitting an “ESI failure”). 

The release method then starts the newly created thread and returns the ESIRelease object to the workflow. The suspended workflow then waits for the “ESI Release Complete” event that gets dispatched from the postEvent() API of ESIReleaseUtility.

The run() method that is executed in the newly started thread does all the useful work, like creating the ESITransaction objects, associating them to other objects as appropriate, generating the ESI response for every destination in the release and sending it to an appropriate destination. When it gets known that a certain transaction in the release has failed, or that all the transactions in the release have been completed successfully, the postEvent() API is invoked. This API emits the “ESI Release Complete” event, thereby causing the suspended RTM workflow to proceed ahead and terminate normally, and marking the end of the release.

The trick here is to suspend the RTM until we emit the "ESI_RELEASE_COMPLETE".

To achieve this do the following:

• Closed-loop transactions enabled with "Enable Post Result" ESI preference set to "Yes".
• Modify the RTM workflow to use the extended class.
• Write the web-service that consume the SAP response and update the workflow appropriately and register.
• extend the ESIResultEvent and override not to emit the "ESI_RELEASE_COMPLETE", (refer to com.ptc.windchill.esi.svc.ESISvrHelper.service.postResult for more details).
• The suspended workflow then waits for the “ESI Release Complete” event that gets dispatched from the postEvent() API of ESIReleaseUtility.
• Call com.ptc.windchill.esi.txn.ESIReleaseUtility.checkAndExecutePostEvent from the Windchill web-service (IE task) when the SAP triggers through web-services - after update.
• Now emit the event from ESIReleaseUtility.postEvent() method.
• Based the workflow variable's value the RTM will routed to either success, failure or aborted.

Hope this solution may work to some one else also, who wants to integrate the Windchill and SAP in closed loop.

Note: SAP web-services is out of scope of this discussion.