How do you convert these external customer numbers into your internal SAP customer numbers?

Some may hard code these conversions into their EDI maps.  This approach can be very high maintenance as customers can add new ship-to locations or reorganize their internal numbers which would require changes to your maps.

Others may set up a cross reference table within their EDI translation table to perform the conversion.  This works well at times, but then you are at the mercy of your EDI group to update the table with any new additions or changes to existing entries.

I find the best way to perform this conversion is within your SAP system.  Mainly because SAP has given you a standard utility to perform the conversion.  All you need to do is populate a few fields of the incoming IDOC and populate the EDPAR table using transaction VOE4 with the internal and external customer numbers.  The Function Module used to process the IDOC takes care of the rest.  SAP uses the Sender Partner Number of the IDOC Control record along with the PARVW and LIFNR elements from the E1EDKA1 segment to look up the correct entry in the EDPAR table.  In your EDI maps you would populate the PARVW element with the partner function code for the external customer number (AG = Sold-To, WE = Ship-To) and populate the LIFNR field with the external customer number received in the EDI file from that partner.  All other fields would remain blank in the E1EDKA1 segment.

Sender Information Partner Number from the Control Record:

E1EDKA1 Segment for the Sold-To Partner (AG):

E1EDKA1 Segment for the Ship-To Partner (WE):

Use transaction VOE4 to populate the EDPAR table.  You enter the value from the Sender Partner Number in the IDOC control record in the Customer field, the function code for the partner in the Ext. Function field.  Note: The Ext. Function field will not be the same as the Partner Function (PARVW) element of the IDOC.  (AG in IDOC = SP on VOE4, WE = SH).  The External Partner is the number received in the EDI data from the customer which is also the number in the LIFNR element of the IDOC.  Int. no is the SAP customer number associated with the External number.

VOE4 transaction with required entries for the Sold-To and Ship-To for IDOC information above:

Using the EDPAR table for customer conversion allows this function to remain in control of those responsible for customer accounts.  Users can be trained to use the VOE4 transaction to update the EDPAR table so when new ship-to or sold-to numbers need to be added they can be done in a timely matter and not rely on other departments.  It also takes this responsibility away from the EDI group so they don’t have to maintain maps or tables for this function.

This function can be used for other incoming IDOCs as well.  You will need to check the Function Modules used to process incoming IDOCs to determine if EDPAR can be used for customer number conversion and on which IDOC segment you would send the external number.

Outbound IDOCs can use either the EDPAR table or the PUMA table to cross reference external customer numbers.  Again, it depends on the IDOC type.  I will cover this topic in a separate blog.

Let’s look at how this process works.  Let’s say we have created an invoice document in SAP.  In this case, the Sold-to, Ship-to, and Bill-to partners are all SAP customer number 15.  If we want to create an INVOIC02 IDOC on which the external customer numbers are populated for all three of these partners we would have to set up three EDPAR entries as displayed on the below screen shot.  The Customer field will contain the SAP partner number (Sold-to, Ship-to, Bill-to).  The Ext. Function field will contain the Partner Function (SP = Sold-to, SH = Ship-to, BP = Bill-to).  The External Partner field will contain the external partner number that the customer is expecting on the EDI file.  And the Int. no. field will contain the SAP partner number (Same as the Customer field).

After we have set up the Partner Profile (WE20) for the INVOIC for this customer we can produce the output through transaction VF02 to create the IDOC.  The INVOIC02 IDOC will display the Sold-to and the Bill-to partners at the Header level in the E1EDKA1 segments, but because we could have multiple Ship-tos on an invoice the Ship-to partner(s) are located at the Item level in the E1EDPA1 segments.  In both segments, the external partner numbers will be populated in the LIFNR element.  The segments for the three partners are displayed below:

As you have probably noticed, the Partner Functions on the IDOCs do not match the Partner Functions in the EDPAR table.  Those would translate as follows: SP in EDPAR = AG in the IDOC, SH = WE, BP = RE.  As you can see the LIFNR field is populated with the values in the External Partner field of the EDPAR table.  These values can now be used in the EDI mapping tool to send the value to the customer.

This is a useful tool as new partners can be added easily using the VOE4 table by a customer service representative.  It also keeps the cross reference within SAP so that the EDI group does not have to build their own functionality to convert the partner numbers and maintain it as new customers are added or locations are changed.

This table can be used for other partner types and other outbound IDOCs.  You would need to check the function module that processes the output to see if it uses the EDPAR table and for which partners.  Another internal SAP table that is used for partner cross reference is the PUMA table.  This is used when creating DELVRY and SHPMNT IDOCs whose function modules do not use the EDPAR utility.  The use of the PUMA table will be discussed in a separate blog.

One such example of additional functionality is the ability to enhance delivered integration content.

Recently, I had to make some modifications to an integration scenario where an SAP ERP system was sending data to an external custom solution.  The good news was the SAP ERP and PI objects were built and delivered by SAP!

SAP ERP Delivered Content

The bad news was that the interface, as designed, did not meet the business’ need…

How to add fields to delivered content?

So, the $64,000 question is, how do we add fields to delivered SAP PI content?

SAP PI Data Type Enhancement

SAP PI data type enhancements allow developers to customize delivered SAP PI content.  Here’s a quick rundown of how it works:

Step by Step SAP PI Data Type Enhancement Instructions

1. First, create a new data type enhancement in the SAP PI ESR:
   
2. Add the required fields to the required data elements and then save and activate your SAP PI changes.
3. The newly created data elements are now in message type:
4. Login to the SAP ERP system and activate the proxy changes via transaction SPROXY.  This will create/update the proxy structures that correspond to the newly created data elements in the ERP system:
5. Finally, create a BADI to populate the new data fields in the SAP ERP system:
   
6. Save and activate your ERP changes. Now you’re ready to rock and roll!

SAP PI data type enhancements blends the stability and functionality of delivered content with the flexibility of custom development. It is definitely one of my favorite advances in the SAP PI platform.

After I stopped laughing, I started to cry, because I realized that this happens all the time in SAP PI–it just looks a little different…

However, most of the time complex mappings can be simplified by using a different approach.  The mapping block FixValues is a great tool to reduce needless. So let’s expand on this example.

Reducing Complexity with FixValues Mapping Block

Let’s say I am developing an interface between a database with information about goods/materials  and a file for system that needs the database data in an easy to read format. To help visualize here is some pseudo-XML of the database:

<Database>
  <row>
    <goodName />
    <goodType />
    <goodQuantity />
  </row>
</Database>

And here is some pseudo-XML of the file layout:

<Report>
  <row>
    <goodNumberUOM />
    <goodName />
   </row>
</Report>

In this example, the database categorizes goods by a category code (A-Z). The type of good determines the unit of measure.  In this imaginary scenario, maybe all but 5 categories have unit of measure assignments.  Everything else has the unit of measure of furlongs.  If we were converting the values using code (ABAP, perhaps?), we could implement the logic using a case statement:

  CASE L_CATEGORY.
    WHEN 'D'.
      L_UOM = 'pounds'.
    WHEN 'C'.
      L_OUM = 'ounce'.
    WHEN 'B'.
      L_OUM = 'kilogram'.
    WHEN 'Y'.
      L_OUM = 'Units'.
    WHEN 'Q'.
      L_OUM = 'SQFT'.
    WHEN 'J'.
      L_OUM = 'Other unit of measure'.
    WHEN 'G'.
      L_OUM = 'Quarks'.
    WHEN 'F'.
      L_OUM = 'Kilograms'.
    WHEN 'E'.
      L_OUM = 'Units'.
    WHEN OTHERS.
      L_UOM = 'Furlongs'.
  ENDCASE.

But how would we accomplish the same using an SAP PI message mapping? Well, one option would be to implement the logic with nesting IF blocks, but that has the nasty side effect of producing the messy message mapping shown above.  Another option is to implement the case statement in a UDF.  But a simpler option exists.  Use a FixValues mapping block.

Here is the same mapping logic using a FixValues mapping block:

And here are the FixValues settings:

Another favorite trick of mine is to use FixValues to evaluate TRUE and FALSE. This can be useful on filtering at the root level (e.g. a requirement to not send a record when the good is a type not relevant to the report you are generating).  In this example mapping, the row will not get generated if the type isn’t a D, A, T, X, S, R, E, or M:

And here are the FixValues settings:

The FixValues mapping block is a very useful message mapping block that can be used to streamline complicated SAP PI message mappings.

• No documentation
• A different means of transport than standard SAP transports (need some training people used to ABAP transports)
• Manual audit accountability (what do you do if you lose an exported PI .tpz file)

To help resolve these issues, SAP released CTS+.  But, what is CTS+ and how can it help?

What is CTS+?

CTS (with out the plus) is stands for SAP’s Change and Transport System.  This is the transport capability of the SAP NetWeaver AS ABAP.   SAP has enhanced CTS with the capability to transport non-ABAP objects–hence CTS+.  Change management on SAP NetWeaver AS ABAP has been a strength of SAP Netweaver for a very long time. In SAP PI, CTS+ leverages this strength by allowing Enterprise Service Registry (ESR) development objects and Integration Directory (ID) objects on the Java stack to be exported and packaged into standard transports that reside on the ABAP stack.

How Can CTS+ Help?

Documentation

With CTS+ you have the ability to document your transport when you create your request. This is amazingly helpful when it’s time to go to production, as you can see what changes were imported and when they were imported. Documentation is also helpful for the Integration Directory (ID) transports, which require activation and input of values.  To get to transport organizer, export what you want to export (namespace, scenario, etc.) using CTS+ (which should be default once it is set up).  Click on create/modification of request and you will see a screen like this:

Here you can put in details of the transport in the description as well as configure various other parameters about the transport.

Additionally, if your project has transport naming standards that require RICEF ID, defect numbers, change request number, trouble ticket number, etc., you can add that information here.

Standardization of Transports

With CTS+ it is possible to configure a standard way of handling transports that is consistent with your ECC environment. This will improve the overall reliability and robustness of environment change management, and will make life a lot easier for the people responsible for handling transports.  Someone accustomed to ABAP transports in ECC but who hasn’t worked with PI can jump in and change management with CTS+ will make sense. CTS+ also allows SAP PI to be compliant with your standard SAP change management governance.

For More Information

CTS+ is available with AS ABAP and AS Java from SAP NetWeaver SPS 12 onwards, although you will have better results with SPS 14 or higher. The following OSS Notes will be helpful:

• 1003674 Enhancement for non-ABAP systems in CTS
• 1145268 CTS+: Changes from NW 7.0 SP12 -> NW 7.0 SP13
• 1146170 CTS+: Changes from NW 7.0 SP13 -> NW 7.0 SP14

In short, CTS+ is a great tool for transport management. It is totally integrated with SAP PI, it is easy to set up, and has huge advantages when it comes to documenting transports and maintaining consistency with ECC standards.

Object Name Prefixes

I have seen a lot of places use prefixes or suffixes before objects such as or dt_ or _mt. I have never really been a fan of these prefixes and suffixes, and apparently neither is the above linked naming convention guide. The reason being is that they are unnecessary. It would be difficult to confuse a message type with a data type in a real interface scenario, even if troubleshooting an unknown broken object. Plus it makes message mapping unnecessarily confusing and long since it’s not clear whether to add the prefix, i.e. MT_one_to_MT_two. Good descriptive names are usually all that you need e.g. DEBMAS_to_Customer. The only possible exception to a no-suffix-or-prefix-policy is the service interface, as sometimes it is useful to know which direction and type a service interface is. An argument for a prefix or a suffix to describe a service interface would be to assist in understanding the flow from an SAP perspective in the event that someone who didn’t develop the interface had to come behind and troubleshoot. A argument against would be the fact that it looks silly if you use it for a web service, because you have a name that doesn’t mean anything to a third party user (note operation mappings are told to omit the prefix of direction and mode in the SAP guide).

One interesting thing that I noticed in my investigation of PI 7.1 EHP1 is that it appears that naming conventions on PI can be validated. If the object names do not conform to a naming convention a message will appear. Ter perform this check in the ESR go to menu Tools>Component Check.

Select “Governance” and “Interface Name Checks”:

If the service interface does not end with (In/Out)(SYNC/ASY) the interface check will show as an error (does not impact interface processing). I created 2 interfaces: one good and one bad to show this error.

My suspicion is that SAP will put more in place to force consistent naming standards depending on the service interface pattern in future releases.

Using a software component and Namespace for each “side” of an interface

All objects of an interface should not be grouped in a single namespace. They should to be split among the Software Component Versions of the systems being interfaced. Otherwise when you go to configure, you will not be able to see your operational mapping (OM) in the dropdown box without having to select all in the dropdown menu. A general rule of thumb is: if it’s not easy to configure, odds are you have probably done something wrong. Another reason why an object might not appear in the dropdown menu (for example for an operations mapping on an interface mapping) would be if the installed checkbox is not clicked on the SLD. When done correctly, most interfaces should be able to be configured quickly and intuitively in the integration directory (ID) without the need to select from all SWCV from dropdown menus on the integration builder.

Whatever naming convention you choose to use for the ESR, the important thing to remember is that adhering to the standard makes production support and troubleshooting faster and easier.

Please note that I was unable to find the wizard for setting it the Services registry in PI 7.1 EPH1, which means I did it manually.

Make sure everything is correct in the Services Registry Management

Go to the NWA (http://host:port/nwa).

Go to SOA Management> Technical Configuration>Services Registry Management.
In theory, there is nothing to do here, however I did specify the discovery URL api parameter as the hostname of the server (no port). If you have changed some settings, on the maintenance tab you can click reinitialize, which should reset any changes you have made back to the initial state.

Configure the ServicesRegistrySiPort

Go to SOA Management> Application and Scenario Communication> Single Service Administration

Click the Consumer Proxies tab.

Search for “ServicesRegistrySi”.

Click on the result and click the Configuration Tab and click on ServicesRegistrySiPort.

The service endpoint name should be ServicesRegistrySiPort.  Don’t change it.

Click security.

You have to give it an http authentication. If you don’t give the authentication, you will eventually have problems like not being able to publish to the SR, even though you may be able to access the registry.

Click on the user ID/ password, click details, and input your http authentication parameters.

Configure the third party UDDI (Only if not using SAP’s UDDI)

If you are using a non-sap UDDI, you will need to go to NWA>Destination Template Management and create a UDDI_DESTINATION and a CLASSIFICATION_DESTINATION to point to the respective urls of your uddi. Don’t forget to click security and select User ID/Password Authentication for both destinations. Otherwise, you will get a 401 not authorized error when you try to access the services registry–similar to if you mistyped your password at ServicesRegistrySiPort.

Security

Make sure that your user has  UDDI_TierN and SERVICES_REGISTRY_READ_WRITE authorizations or you will get a 401 not authorized error.  Of course. in your system you should use a technical user instead of your userid as which I did for the purposes of this blog.

Please note, I did run into an issue where it suddenly stopped working a day everything was configured. All I can say is Gremlins. I switched the user to a technical user with the authorization listed above on the ServicesRegistrySiPort as well as on the destination templates and I haven’t had a problem since.

To update the runtime cache (called CPA Cache), enter the following URL in your web browser http://<host>:5<sys#>00/CPACache/refresh?mode=full. XI will do the rest of the work for you. After the CPA cache is refreshed, the new RFC meta data reflects the newly added fields.

These other CPA Cache URLs may also be helpful:

CPA Cache Monitoring: http://<host>:5<sys#>00/CPACache

Delta CPA Cache Refresh: http://<host>:5<sys#>00/CPACache/refresh?mode=delta

Full CPA Cache Refresh: http://<host>:5<sys#>00/CPACache/refresh?mode=full

By default XI/PI allows message mappings, Java class maps, Java XSLT maps. All these mapping types execute on the Java Stack. There are times where mapping could/should be done on ABAP stack. XI/PI allows for the ABAP stack to handle mapping, but it is not enabled by default.  My next blog posting will cover when to use a ABAP map and how to implement transformation in ABAP.

The graphic at left shows the default mapping types in the Interface Mapping definition of the Integration Repository.

The first step to enable ABAP stack mapping logic is to navigate your browser to the SAP XI/PI Administration application.

We will be modifying the Exchange Profile to allow SAP XI/PI to utilize the additional mapping types.

The Exchange Profile setting we want to change is com.sap.aii.repository.mapping.additionaltypes.  This setting is located via the following hierarchy: “IntegrationBuilder\IntegrationBuilder.Repository”

Once you navigate to the correct Exchange Profile setting, enter the following value:

R3_ABAP|Abap-class;R3_XSLT|XSL (ABAP Engine)

The above string specifies that, in addition to the standard mapping types delivered by the Java stack, we will also be using ABAP code, and XSLT translations using the ABAP stack.

Once you have entered the data, press the save button.

Changes to the Exchange Profile require the Java instance to be restarted.  When appropriate, restart the Java instance.

Once the Java instance has been restarted, the new mapping types can be seen in the Interface Mapping definition of the Integration Repository.  Your SAP PI system is now ready to execute data transformations using the ABAP stack.

For more information, refer to SAP Help.

Most SAP PI developers have had a situation where a relatively minor change to the target message causes real havoc to the entire message mapping.  For relatively small maps, it may not be a big deal. For maps with complex logic, this can be a big deal requiring hours of tedious rework.  Recently, I was faced with a requirement change that required my message mapping to change correlations from 1:1 to 1:N. Since this interface used the RFC adapter (which supports multiple messages), I was able to implement a 1:N multi-mapping message split. In the new interface design, the file adapter will process one file and pass it to the integration engine. The integration engine will perform a multi-mapping message split to break-up the message. The new, individual messages will be sent via one adapter engine call to the RFC adapter. The RFC adapter will handle each message individually, calling each in a separate logical unit of work (LUW).

The steps below will detail how to switch a message mapping from a 1:1 correlation to a 1:N correlation without remapping anything!

Note: The steps outlined below assume a moderate understanding of SAP XI/PI and gives does not give comprehensive instructions for every step. Please post any questions to the comments section of this blog.

• Step 1 Before starting anything, make a safe copy of your message mapping. This will give you the ability to perform before and after comparisons and afford you some protection if something were to happen to your original mapping
• Step 2 Use the hidden menu command (<Ctrl> + <Shift> + right click for those of you not paying attention) to download the current version of your message mapping.  SAP PI will save a file with the extension .mte.
  The .mte file you just exported is really just an XML file. Opening the .mte file in Internet Explorer will yield something that looks like this
  
  The entire message mapping is contained in the file, including any user-defined functions, brick layout, and test cases.  This will be very useful!
• Step 2 Change the target occurrence in the message mapping. This is done on the Messages tab of the message mapping.
  
  Changing the occurrence on the target message appears to have little effect on the message mapping, until you switch back to the Design tab and you see this ugly message box:
  
  Oh noes! PI added <Messages> and <Message1> tags to the source and target messages! Since the target message structure changed,  all of my hard-fought mappings are lost! Who can save me from hours of tedious remapping?
  Fear not, plucky mapper, in a few steps, you can save the day by  converting the entire map without remapping a thing!
• Step 3 Use your favorite text editor to open the .mte mapping file.  We will use the find/replace functionality to mass change the source mappings.  You will need the services of the copy of the map you made in step 1.  To get the value to find, copy the path of the root node in the unscathed map. To get the value to replace, copy the path of the node just below the <Message1> node in the new map.
  
  Here is the find/replace text for the example in the graphic:

  Replace:
/ns0:Personnel_MT
with
/ns0:Messages/ns0:Message1/ns1:Personnel_MT

• Step 4 Repeat step 3 for the target message.Replace:
/ns1:Z_BAPI_II_KENEXA
with
/ns0:Messages/ns0:Message1/ns2:Z_BAPI_II_KENEXA

  Save the .mte file in the text editor

• Step 5 Providing you didn’t inadvertently screw something up, you should be able to import the .mte file to the Integration Builder
  
• Step 6 Now change the occurrence on the corresponding interface mapping to match the message mapping occurrence set in step 2.  Save and activate all of your changes.
• Step 7 The final step is to change the Interface Determination in the Integration Directory to utilize your new multi-mapping message split.

As you can see, the ability to export/import message mappings can really save you a lot of time. If you have any other tips regarding message mapping export/import, please share the in the comments.

Happy Mapping!!