39. Further Information ď¨ Public Web: http://www.wfmc.org â Workflow Management Coalition www.sdn.sap.com - SAP Developersâ Network ď¨ Related Workshops/Lectures at SAP TechEd â05 EPI104 â Interoperability SAP NetWeaverâIBM WebSphere, Lotus, and Tivoli EPI200 - ASUG Workflow/Webflow SIG Community: Tips, Tricks and Information Sharing Session ď¨ Americasâ SAP Usersâ Group (ASUG) www.asug.com
40. THANK YOU FOR YOUR ATTENTION ! QUESTIONS â SUGGESTIONS â DISCUSSION
41. Feedback Please complete your session evaluation. Be courteous â deposit your trash, and do not take the handouts for the following session. Thank You !
42.
Editor's Notes
In this example, weâve used a dialog user. It needs to be pointed out that a Communications user is actually the ideal type of user for this application, since they can not log in as a dialog user can.
This step needs to be done in both systems to enable communication. The called system will need to be able to create XML documents in the calling system through this service.
If a workflow finishes almost instantaneously, the document interchange may become confused, which will result in error.
Without the reference workflow, you would have no context for binding the local workflow to the remote workflow.
Creating the reference workflow ahead of time may save you some trouble later when creating a web activity to call a remote system.
The calling workflow is an entirely different template than the reference workflow. It will use the reference workflow interface to exchange elements with the remote system.
The transfer format may be one of several versions of Wf-XML, as well as one or two other encoding schemes. Note on extra dialog: this dialog allows you to create your reference workflow on the fly, but it can cause issues with object locking. It also may be difficult to adjust the container interface and/or activate the newly created reference workflow if it is created here. It is much easier to create the reference workflow first, in a separate step, as we have done in our example.
The hostname and port number were entered in the remote system in transaction SWR_WEBSERVER. The workflow template number is the number from the REMOTE system. This needs to be differentiated from the reference workflow number, which will be entered in a different location a couple of slides later.
Two sets of documents are created if the âWait For Feedbackâ box was checked in the Workflow Builder. Only one set of documents is necessarily created in the other instance (the CreateProcessInstance.request set). The second set indicates that the remote workflow has finished, which is only useful if you have instructed your calling workflow to wait for this information.
Mention work item ID at left side again. This transaction can be reached (for individual documents) by double clicking in SWXML. Mention needs to be made about error processing; specifically that it is done through the workflow log, where you can automatically navigate to this transaction.
Different versions of Wf-XML may be used. The standard specifications are also available at http://www.wfmc.org.
The header section contains the URL of the called system. The bodyâs ObserverKey section contains the callback URL which will be used in the ProcessInstanceStateChanged interchange. The ContextData section, according to the spec, is completely free form. SAP, when generating documents, uses the above format for passing elements bound to the reference workflowâs container.
The immediacy of the response should be stressed, as in: the data returned from the HTTP request made with the originating document must actually contain the response document. Any other data returned immediately by the remote server will result in error. The MIME type is only of concern when dealing with Non-SAP systems. SAPâs Workflow environment will automatically generate documents of the correct type
REQUEST DOCUMENT: The state that is passed informs the calling system of the current state of the remote workflow. The remote workflow will export container elements in its âResultDataâ section (corresponding with the ContextData section in the previous slides). RESPONSE DOCUMENT: Returned immediately by the calling system, similarly to the process in the previous slides.
Any language could be used on the web server in the example, as long as it immediately returns a proper Wf-XML document. In this example, a background process is not launched by the script, but there is no reason it couldnât run some background programs that send a ProcessInstanceStateChanged document back to the R/3 system upon completion.