I’m currently using the SAP Adapter to route my SAP IDOCs (via routing rule) into the trading networks via the “…/routeXml” service (after converting the IDOC to an XML doc.). However, this presents a problem of double storage. I have the IDOC stored by the Partner Manger and also in TN Server’s Database. I want to use the TN Server Database as my primary storage. However, I can’t see how to disable the Partner Mangager’s transaction storage.
I was hoping some of you folks would have an answer for me on how to disable the Partner Manager’s storage of the transaction. Or, perhaps you know of a way to route IDOC’s from SAP without using the Partner Manager.
There is indeed a way to do this. Gleened this from the SAP Adapter User’s Guide which barely touches on this. In Chapter 8 on page 8-2 it states:
“The Partner Manager receives IDocs from an SAP system if the tRFC (INBOUND_IDOC_PROCESS or IDOC_INBOUND_ASYNCHRONOUS) has no inbound map associated with it.”
So the trick is to define a couple of inbound function maps in the adapter config pages, one for each of the tRFC types listed. Define the maps to invoke a custom service that you write. With these function maps in place, Partner Manager never see the docs. Be aware that there are still logs and such created by the adapter that you’ll need to clean up periodically to conserve disk space.
The custom service needs to do some house-keeping and then can pass the doc on to TN. Here’s the overview of steps:
The service inputs will be the usual IDOC_CONTROL_REC_40, IDOC_DATA_REC_40, IDOC_DATA, IDOC_CONTROL that the low-level adapter services use.
There will be a $action variable in the pipeline. If it is greater than 1, do nothing and simply return. The function map service is called multiple times–once for “here’s the data” and then again for “commit.”
Call sap.idoc:decodeSDATA then pub.sap.idoc:transformFlatToHierarchy and finally pub.xml:documentToXMLString to get the XML form of the IDoc. Sounds like you’re familiar with this part already.
Way cool, Rob! We did quite a few SAP integrations, and I guess everyone missed that part of the User’s Guide! From all indications, it seems that very few people @ wM is aware of this, e.g. WmPartners is still available as an optional package in IS 6.*; also that we did have official answer from wM support that Routing Rules (WmPartners) are unavoidable; and that the SAP Adapter’s structured (looks like) configure things using WmPartners.
For inbound iDocs (BC -> SAP), I actually prefer going through Routing Rules, since that seems to be the preferred way the SAP Adapter’s set up. But having a delivery service for iDocs in TN would be oh sooo nice. That would meaning being able to put the iDoc delivery into TN tasks. I thought about implementing one, but it’s daunting to make it configurable from w/in TN Console…
Yeah, wM support seemed very concerned about this setup when they first saw it. They said the docs must go through WmPartners. But after explaining how things were set up and that it was working they seemed fine with. However, I’m sure they still prefer things go through WmPartners. I don’t like using WmPartners primarily because it is old (TN replaced it all intents and purposes) and TN needs to be used for everything else–thus we’d need two quite similar facilities. I’d fully expect the next version of the SAP Adapter (if there will be one) to do away with WmPartners and make full use of TN.
Even if you have the doc handled by WmPartners, it still ends up invoking a service you write. That service can pass the doc to TN to get access to all the TN facilities.
Custom TN delivery services are not terribly difficult. You should be able to create one that takes an XML IDoc and interacts with the SAP adapter to send the doc to SAP. We didn’t do that in our last SAP project because there was another path to SAP that was used.
I am sending the document(iDoc) from SAP to TN directly using wm.tn.receive service in routing rules.The problem is in identifing the document through document types , what I need to enter like root tag, ID and pipeline key-value pairs and what more I need to enter.
It is the Idoc in pipeline, so what I need to enter in Idenity tab.
Kindly, could you help me in creating document type in this scenario
you cannot send the IDOC directly to TN.if you do so,TN will not recognize the document type.First create an XML Document type in TN and then convert the IDOC to XML and then route it to TN.This solves your problem.Go through the SAP Adapter’s guide.
Routing rules invokes a user defined service, in which you have to convert the IDOC to XML.I dont remember on top of my head the services to use to convert the IDOC to XML.You are in the right direction.Debug the flow carefully and check whether the IDOC is being converted to XML.After this step, invoke tn.receive service to route the XML to TN.Also check if you have correctly defined the identifying queries for the XML Document Type in TN.
For converting IDOC to XML use the SAP Adapter service.
pub.sap.idoc:FlatToHierarchy service this parses the idoc gives IDOC_Control_Rec_40,IDOC_Data_Rec_40 record structures based on the IDOC schema/doctype you are using.Once these structures are in pipeline map it to your XML record,and for routing to TN use routeXML service (map node to it)…
We have tried the same, while we route to TN by using the service routeXML , the entire pipe line data is getting stored in TN and it is not matching the doucument type.
We have created one document type(XML) and the same has been selected in the processing rule. We have specified some conditions , with no conditions also in the DT but TN doesn’t able to match the document type.
we are getting sender, receiver, document type all are unknown.
Can you help us to match document type in TN for an XML document.
Please help us to move further. Any inputs are greatly appreciated.
Did you see which rule it is selecting in the Activity log?It should trigger your created processing rule and make sure this rule is above the default rule using shiftup icon in the processing rules section.
Thanks a lot. We have specified our processing rule before default.In the activity list it is saying “Routing rule matches anything selected” . It is not able to match the document type in the processing rule. Please give us some more inputs.
Hi Chad
Thanks a lot.We are not finding any “extraneous” variables in the pipeline. What ever we have define those are getting populated in the pipeline. Please give us some more inputs.
How were you able to match the Document Type in TN while you were sending the pipeline data to TN? We are unable to match the Document Type. Can you please suggest us with precious inputs?
How were you able to match the Document Type in TN while you were sending the pipeline data to TN from IS? We are unable to match the Document Type which is a primary constraint in TN. Can you please suggest us with precious inputs?
Anybody had faced the same obstacle , Could please guide us.
How were you able to match the Document Type in TN while you were sending the pipeline data to TN from IS? We are unable to match the Document Type which is a primary constraint in TN. Can you please suggest us with precious inputs?
Anybody had faced the same obstacle , Could please guide us. We tried for all optins like Declaring the Document type as XML or Flat file in TN but we are uanble to match , we tried even matching the pipeline data in DT criteria but it didn’t workout. Appreciate for your inputs.
Do you see your unmatched document to TN, and execute a query on the TN database using the document type “unknown” as the sole selection criteria?
You can (if all other attempts to adapt the document type fail) select this unknown document type from your criteria and use that record to build a document type. Simply highlight the TN record, right click, and select edit/create document type.
You could also use this process to determine how your document is representing itself to TN, and make the necessary changes to your posting service.