SAP Integration Suite Trading Partner Management: How to use parameters?

[philippeaddor]

I'm trying to find out how to use Parameters, that are defined on a partner company in the Trading Partner Management, in my Integration Advisor mappings. The whole concept of Parameters in TPM is not well described in SAP Help, unfortunately.

I managed to import the param key/values via CSV import on the partner. Then I can add them in the Partner's Agreement using the "Parameters" button:

However, I see no way to make use of them in the MAG. There is another function of "Global Parameters", but values have to be maintained directly in the MAG, which is not helpful if you want to give access to the data to end users... Has anybody foudn out how to link the TPM Parameters to the Global Parameters of a MAG?

[MarcoErtel · Accepted solution]

Hi Philippe,

it is relatively easy to use:

1. define a global parameter in the MAG (https://help.sap.com/docs/CLOUD_INTEGRATION/368c481cd6954bdfa5d0435479fd4eaf/62fe053efca84891aca7ce4477f82c77.html)

   

2. use the global parameter in the MAG (https://help.sap.com/docs/CLOUD_INTEGRATION/368c481cd6954bdfa5d0435479fd4eaf/2ea22d0fbc14405b82e77b12fb24f3a1.html)

   

   

3. test it with the simulation inside the integration advisor
4. overwrite it with the parameters from TPM (use the exact same name)

   

I agree that the documentation around these topics definitely has room for improvement and we also need to write a blog to explain it with more details.The parameters can also be used to modify other values of the messages (e.g. sender/receiver id, ...).

Kind Regards
Marco

[philippeaddor · Accepted solution]

Hi Marco,

Thank for the explanation! Once you know how things are linked together, it's easy, I agree :-). Will try it out. Now it's at least documented here.

Next related question would be what an Activity Parameter in an Agreement is and how it's used. The documentatin is very generic about this too.

UPDATE: I think I just answered my own question: It's simply a parameter that is added directly in the Agreement instead of extending one from the partner or company data.

Philippe

[bhavesh_kantilal]

dc01fe2c84194f24b77a64b3dbe421fd vijaykonam -> Just in case you reach the point like me to access the TPM Parameters in your Custom Flows, you would need to use a bit of Groovy magic.. Just in case you need that you can go directly to the section 5 of this post of mine - Trading Partner Management – Part 11 – Handling Parameters

[philippeaddor]

Thanks Bhavesh for the information and linking my question here in your excellent blog! (which I wish I had when I started using TPM myself) 🙂

[VijayKonam]

SAP documentation has been less then impressive with respect to TPM so far. There was lot to dig and understand. I hope to see someone answering this. Watching the thread.

[Ryan-Crosby]

I was less than impressed and chose to build an EDI package from scratch because of some of its shortcomings - unfortunately, I won't be of any help in this space.

[VijayKonam]

I was able to at least figureout both inbound and outbound scenarios with As2 and Idocs and was able to test. Did not explore into parameters and MAGs. I would like to skip MIGs as much as I can as the out of the box iflows/the TPM agreements allow us to plug in our own maps in an iflow. Will check when I get time.

[philippeaddor]

Thanks both for your answers so far. ryan.crosby2 , you could also just copy the standard iflows and modify them as needed. I did that to overcome the fact that SAP forgot to make the "Proxy Type" configurable (for the IDoc receiver, that often is on prem and not in the internet...). Apart from that, I like actually the standard TPM Iflows.

vijaykonam You're right, it was a lot of trial and error for me too to make things flow. But once you get the hang of it, it's pretty nice. Why do you want to skip the MIGs? I think the IA concept (MIG/MAG) is quite neat for EDI mappings. My plan is to only resort to custom maps in case something is not feasible with IA. Curious to know what your requirement is and how you build your EDI mappings instead.

[VijayKonam]

IA is still in it's infancy as I see it. They say AI, but I don't get any useful proposals even for the simplest EDI documents. We may develop fresh maps using IA, but for migration objects, I would like to reuse PO maps.

[Ryan-Crosby]

dc01fe2c84194f24b77a64b3dbe421fd Unfortunately, I find the push to maintain mapping objects per partner, and the lack of support for bulk sending overly cumbersome and largely disappointing. I went ahead with a similar approach, but focused on singular mapping objects with options for extended pre/post processing, and the inclusion of support for bulk sending which should be included in any EDI framework - Outbound EDI and Inbound EDI.

[philippeaddor]

ryan.crosby2 Wasn't aware of your blog. Great work! Very clean and comprehensive. Added to my library!

Since we don't have the bulk processing requirement, this is not an issue for me.

Regarding the single mappings objects per partner: We're just at the beginning of our EDI greenfield implementation with IA/TPM. Our plan is to simply copy and modify MIGs/MAGs per partner where necessary. I don't really see a disadvantage in this (frankly I only skimmed through your two blog posts so far, might have missed your main motivation for the custom implementation). I'm rather pro separation of mappings per partner to avoid side effects due to modification of a global mapping based on a new requirement of a single partner or so.

Besides that, we thought we theoretically >could< build global mappings and use pre/post processing (XSLTs and, since Q4, also own pre/post-processing intergration flows) to do the partner specific detail mappings (which is also what I would resort to in case of mapping logic not feasible to implement in a MAG). Since this is part of the TPM features (and of the standard IFlows), I would like to understand why exactly you wanted to reimplement this. I haven't made use of these features yet, so I wonder if I'm missing something.

[Ryan-Crosby]

dc01fe2c84194f24b77a64b3dbe421fd the main disadvantage I see with maintaining the individual artifacts per partner is the amount of maintenance that is required as the number of partners increases. Take for instance a situation where we want to output a new piece of information to a global mapping... we cannot simply update the single mapping, but we must rather update the corresponding mapping in the partner directory for n partners - not exactly straightforward when having to convert artifacts to base64 and upload to the partner directory. That also raises the question of how to keep those "global" mappings in sync. The additional one is the use of bulk sending which to me is another glaring miss by SAP because it's commonplace to be able to send multiple transactions at one time... it's even supported with the splitter on incoming messages.

Regarding the customization partner specific... I have already made use of the pre/post mappings in a handful of instances across 810s, 850s & 856s and been able to handle every funky partner nuance, even when their requirement violates the general semantics as long as it doesn't violate the syntax. Have to remember that the point of EDI is to not build the same integration over and over again.

[philippeaddor]

ryan.crosby2 Totally agree with your points! Reality is unfortunately a little difference when it comes to partner's interpretation fo the standard - or the standard is too loose maybe. And I perhaps naivly hope that we will rarely to never have such a thing as a new piece of information that has to be output to all partners... But if, one would have to swallow the bitter pill and go through every MAG. At least, Trading Partner Management does all the cumbersome handling of the Partner Directory (no need to encode and upload mappings manually, just activate the partner Agreement).

[VijayKonam]

ryan.crosby - I do not think we need to convert the maps to base64 and upload to PD using APIs. We could simply put the map in an iFlow and link iFlow in TPM agreement. At least, that is what I tried and it works. Never want to deal with PD parameters using Postman. A nightmare.

[Ryan-Crosby]

vijaykonam yep, apparently that's a drawback to not using the TPM, but on account of the other shortcomings I'll skip it for now. dc01fe2c84194f24b77a64b3dbe421fd I forgot... the other item I included is the ability to record functional acknowledgement status back into SAP using the datastore functions and the SYSTAT01 IDocs. Last I saw in the TPM there was no facility to handle this flow of information.