We operate in an environment where any integration to our TM system has to go through SAP PI (or PO as it is now called). This is an architecture choice we have made that is valid irrespective of whether we are integrating other internal systems (SAP and non SAP) or those of our partners.
Whilst getting two SAP systems to talk to each other is usually simplified due to SAP offering out of the box functionality to do so , integrating non SAP systems to a SAP system is less so. Simplistically, for starters a certain effort is required to analyse which fields map to each other as well as determine which conversion and transformation rules need be to be applied. Once that is done you then need to get together the TM expert, the PI expert,
quite possibly a developer as well as maybe a basis resource for good measure (I purposefully exaggerate, but if you find ONE person that does it all, then hang on to them). More often than not, this is not a productive way to go as each person’s work will involve a certain amount of trial and error which unfortunately leaves some waiting around whilst others are still trying to figure things out.
Back in the days when IDOCs were the talk of the town (don’t read anything there – I am very fond of IDOCs) , we had transaction WE19, which is a transaction that allows you to craft an IDOC directly in SAP and send it to the application for processing…and testing! You were actually able to fill the IDOC with the fields you needed, test combinations, scenarios… In other words you were able to write your data requirements specification as you went along testing your IDOC, before passing it on to the person looking after the data provider to make sure he sent you that information. This would prove to be a huge time saver. You’ll be happy to hear that this method can also be applied to enterprise services. To illustrate this, I will use the scenario where I will be integrating TM with an external party. The external party will send me a file that will result in the creation of forwarding orders in our TM system. So how can I go about identifying which enterprise service to use, and then the data elements required for the chosen service to work?
In this post I’ll describe the process I went through and hopefully distil a few tips that others will find useful.
Identifying the service
My starting point was to read the document published by SAP titled “SAP Transportation Management (SAP TM) Release 9.0 (Enterprise Services)” which is available on the SAP service Market Place – you can find it here in the application help section (OSS id required).
Going through the document, on page 163, I found exactly what I was looking for, which was the description of the service Maintain Transport Request. Its definition reads, (service) “to create, change, or cancel a transportation request of the category forwarding order”. Great ! The technical data header also provides important additional information, to be specific:
- The Release state is “Released with restrictions” which essentially translates to proceed at your own risk. However things are looking up, as up to TM8.1 this service was restricted.
- The namespace which is http://sap.com/xi/TMS/Global – this will be handy a bit later when you navigate the ESR hierarchy
- The technical name which is TransportationRequestRequest_In
- The category which is B2B (Business to Business)
- The change/update behaviour which is of type 1 – this essentially means that every message (whether it is create or update, it must have all elements filled)
- This service has Point to Point communications enabled (i.e the consumer can talk directly to the provider – but not applicable to us as we will go over PI)
So far I’ve identified the service I want to use, but have no idea of what information (optional vs mandatory, format…) I will need to pass to the application in order to successfully process the inbound message. My next stop is to go the Enterprise Services Workplace . Here I find additional details on the service I am interested in. Indeed, the Maintain Transport Request page provides the following information:
A reference to OSS note 1512334
This note is a gold mine. From it you can download zip files (select one depending on your TM version & level) which includes for each service of both the TOR and TRQ objects family one pdf file with a detailed explanation of the service as well as an excel file which recaps the entire structure of your message (this I would foresee would also be a good starting for mapping your service to data providers). A glimpse of this excel file is shown below.
Click to enlarge
It provides me with the name of the Business add-in (BAdi) I could enhance, should I need to add my own enhancements. That BAdi is ‘/SCMTMS/TRQ_SE_TPNRQ_REQ’. So now that I have all the information I need I can get cracking and code the xml file that I will use to simulate the inbound message. Now, if you look at the elements of this service you will instantly notice that it is quite a long one and it could take me hours to craft one from scratch. So let’s be intelligent about this. If you think about it the forwarding order I want to create in my system could very well come from a partner’s freight order (or similar). So what I can do here is generate an outbound, freight order based message from my system and use that. To do this, you just need to go to a freight order and then select the menu option Subcontracting / Send to carrier. This will generate a message of type TransportationOrderRequest_Out. You can then easily download the associated xml payload using transaction SXMB_MONI.
Simulating the Interface
Recapping where we are: I used an outbound freight order message as a basis for crafting an inbound forwarding order message (makes sense right !!). I now have an xml file, that I hope looks like my inbound file should look like. To test it I go to transaction SPROXY (you could also use SE80) and access the ESR (Enterprise Services Repository). I navigate the hierarchy until I find my service interface (TransportationRequestRequest_In).
To begin the test, you simply need to click the test icon . The following popup will appear.
Pressing F8 to continue will invoke a window similar to the one below.
It contains a template xml message. We are going to replace its content with that of the file I created earlier. To do so just switch to the xml editor, delete the content of the template file (Ctrl A then delete) and paste in the content of the file you crafted earlier. Switch back to html control and you should now have something like this.
You can then use the appropriate icons in the toolbar at the top of the screen to check the formatting of your code and execute the inbound message processing. If everything is OK, then you will receive a success message in the bottom status bar similar to the one below:
As indicated by the message you need to commit the work , by selecting the menu Extras / Trigger COMMIT WORK. If you don’t then your forwarding order will not be created. That’s all there is to it.
NB: I’d like to thank the good folks at SAP (you know who you are), who helped me work out that the ‘SenderBusinesssystemsID’ element needed to be filled, even though the documentation did not have that as a mandatory field.
This has been cross posted from pascalrenet.com