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!!

Now that I’m a little older, I’ve graduated from NES to SAP PI.  It’s not nearly as fun, but every bit as challenging.  And at least I get paid to do it.  I looked, but could not find anybody to pay me to play Contra.  Instead of the many end of level “bosses” the only boss I have to worry about is my project manager–I don’t know which one is more evil.

Similar to Contra, the message mapping editor in XI/PI has a menu with helpful items that is “hidden.”  Unless, that is, you know the secret key combination to unlock it. In PI, open any message mapping in edit mode.  While holding the <Ctrl>+<Shift> keys, right click in the data flow editor window.  You will be rewarded with this menu.

Here is a short rundown of some of the menu options:

• Last Used This menu keeps track of recently used mapping functions. It can be a real time saver if you are using mapping functions from multiple function groups.
• Tools\Export Tools\Import The import/export functionality of the message mapping editor is, single handedly, the best feature of the hidden menu.  The import functionality allows you to transfer message mappings from disparate SAP PI systems.  The import/export functions also can reduce work in other ways that I will discuss in detail in later blogs.
• Tools\Export Tools\Export The export function downloads the source of your message mapping to your local hard drive.  The file includes the map’s header data, data flow logic, user-defined functions, test cases, and documentation.
• Tools\Color schema\Schema XI20 SP3 This option changes the data flow editor color scheme to look like it did in XI2.0 SP3. I never used XI 2.0, so I don’t know if this color scheme is accurate. I can tell you, however, that the brick colors are brighter in this color scheme
  
• Tools\Color schema\Schema XI30 “accessible” Personally, I really like this color scheme. The data flow editor’s ugly grey background is replaced with a more eye-pleasing white. I switch to this color scheme whenever I am capture screen grabs of the data flow editor for documentation purposes.
  
• Tools\Local Compilation While I’m not quite sure exactly what this option does, I would assume that it changes on which system the compilation of the map occurs.  When checked I think the compilation of the map would occur on your workstation instead of the server, but I have not been able to confirm this thru testing, nor have I found any documentation to support this claim.
• Tools\JarClassTest This togges the JarClassTest option.  I have yet to detect a difference in the behavior when compiling/testing, nor have I found any documentation on this item.  If anybody out there has any information, please post a comment.
• Tools\Autosize Bricks This function is useful, especially if you have fields or user-defined functions (UDFs) that have long names.  By selecting this menu, you no longer have to guess what field or function each brick is for.
  vs.  
• Encoding This option allows you to change the encoding in the XML tag of the target message

At a client of mine, I had to develop an interface to accept a file with IDOC acknowledgments. Our SAP system was sending data to an external system and the external system was sending back status messages that we were to post using ALEAUD. The status file was written periodically and could contain any number of records. Each record needed to be its own IDOC. The problem is that there is no “out of the box” solution that allows 1:N file to IDOC mapping. I searched a bit on SDN and found that there were others with my same problem. All of the responses, however, suggested using BPM. That just didn’t seem right to me. BPMs are great and all, but I don’t feel like I should need to implement a BPM to do something as simple as 1:N correlations. I set out to find a better way to do 1:N correlations with IDOCs and found that is actually was real easy.

After doing my research, I found that the issue is not with the IDOC adapter nor mapping engine, but rather the issue lies in the meta-data imported from the ECC instance. The meta-data describing the IDOCs has an element occurs of “1..1″–i.e. each message that contains an IDOC can contain one and only one IDOC. As it turns out, SAP handles the case if multiple IDOCs are passed to the receiver IDOC adapter. The mapping engine can easily handle multiple IDOC occurrence. The only limitation is the IDOC meta-data and, as I will show you below, that is an easy limitation to overcome.

1. First, in your XI integration repository, download the IDOC definition from your ECC/R/3 instance as you normally would for any standard IDOC integration scenario.
2. Complete the message mapping and the rest of the integration scenario development as usual.Notice how the source message has an occurrence of 1..unbounded, but destination message is limited to an occurrence of 1..1. If the mapping were to remain this way, no matter how many IDOC tags would be in the source XML, one and only one IDOC tag will be created in the resultant XML. We’ll take care of this next.
3. Export the XSD for the IDOC to a file on your PC.
4. Open the file in a text editor and change the element named “IDOC”. Add the following text:minOccurs="1" maxOccurs="unbounded" Save and close the XSD file.
5. In the message mapping created in step 2, import the XSD created in the previous step as the message reference for the IDOC. Notice how the evil “1..1″ occurrence constraint on the IDOC tag is now “1..unbounded”!
6. Multiple rows in the file will create multiple IDOCs! Are you as excited as I am?

So, what did we learn today?

• You aren’t completely locked into the meta-data derived by SAP.
• The reciver IDOC adapter is pretty forgiving (much more so than the sender IDOC adapter–more on that another day)
• Most importantly, it is possible for a 1:N multi-message IDOC reciver correlation without BPM!

This blog was originally created on another blogging site. Recently, DataXstream migrated its web server to a platform that makes it easy to blog.  The first couple of posts to this blog will be reposts of entries from the old site.

Some topics in this blog will be very technical and may need some clarification. Please don’t hesitate to post questions, comments, or concerns.