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.

SAP Learning Seminar

When: Fri. Sept. 24

7:30 AM – 5:00 PM

Where: Holiday Inn – Williamsburg, VA

Cost: Free

Register for the Event

Can’t make it to Las Vegas for TechEd this year?

Join us September 24 in Williamsburg, VA as we host an SAP Learning Seminar for the VA/NC ASUG chapter. ASUG, DataXstream, and event sponsors have scheduled a full day of  presentations by industry experts and local SAP users, panel discussions, and interactive breakout sessions and workshops; all intended to give you a great learning experience and stay abreast on everything current in SAP. DataXstream’s sessions include:

Solution Manager Optimization

• 11:00 AM – 12:00 PM
• Tim Cooper, Sr. SAP Consultant, DataXstream

SAP PI 101

• 1:00 PM – 1:45 PM
• David Morin, Sr. SAP PI Consultant, DataXstream

Lessons Learned During Implementation

• 3:00 PM – 3:45 PM
• Timothy Yates, CEO, DataXstream
• Chuck Newara, Director, Lumber Liquidators

Download Full Agenda

Directions

• 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.

Part One – The Integration Directory (for PI 7.1 or greater)

I decided to start with the Integration Builder because it’s the easier component with which to bring everything into alignment (versus the ESR). Most of the time there are only two things to name: the scenario and the communication channel.  Unfortunately, it is still incredibly easy for objects to become disorganized.

Configuration Scenarios

The whole purpose of a configuration scenario is for organization. An interface will run whether it is in a scenario or not, however troubleshooting is much more difficult when objects are not properly organized. It is important to use a naming convention that addresses the business purpose of the interface and is specific to the flow of the interface (to help with troubleshooting issues and make flows easily traceable).  To accomplish all of these requirements, DataXstream recommends a naming convention that includes the specification number which originated the development request and a route number. The route number is used in interface diagrams and documentation and assists production support with identifying objects in the event that a business scenario involves multiple destinations.  We also recommend including a statement to describe the flow for the route, as well as the description of what the interface does. Some examples of a naming convention we might use would be:

0001.001_ECC_to_Partner1_TransactionalDataDistribution
0001.002_ECC_to_Partner2_TransacationalDataDistribution
0002.001_Partner3_to_ECC_SomeInboundInterface
0003.001_Partner4_to_Partner5_SomeNonSAPInterface

The other thing of note is that all objects should exist in a scenario, even if in a test_DONOTTRANSPORTTOPRODUCTION_prototype_interfacedescription scenario. Proper organization makes it a lot easier to identify, modify, turn on and off, and troubleshoot interfaces. Fully configured interfaces running in objects view take more time to understand and are more time consuming to fix.

Communication Channels

Communication channels should describe the purpose, type, and direction of communication. However a lot of people include unnecessary components in the communication channel. For example, since there are usually only two objects with names in the IB, it is not necessary to prefix a communication channel with cc_ as it is unlikely to ever be confused for a scenario. A lot of people also include the communication component in the name of the communication channel, but that also seems redundant, since only communication channels exist under communication components. Some things that are valuable in looking at communication channel naming convention are knowing a brief description of the process it involves, a direction of the communication channel, and the type of adapter being used. Some examples of naming conventions we might use are:

Logistics Company

• PO_file_sender

Database System

• materialSqlXml_jdbc_receiver

ECC system

• IDoc_receiver

As you can see, it is possible to keep the name descriptive and helpful without making the name overly verbose when it comes to communication channels.

The order in which the naming components are ordered depend as much on personal preference as anything else.  For example, let’s examine a sender file channel that pertains to purchase order data.  Some of the naming convention options are:

• Sender_File_PO: groups all sender and receiver channels together, then groups by adapter type
• File_Sender_PO: groups communication channels by adapter type, then by sender and receiver
• PO_File_Sender: groups by logical interface payload, then adapter type

Other Things To Watch Out For

• Configure the unnecessary- We all know that no sender agreement or channel is needed for certain communication methods like iDoc or SOAP to the IE, but if you can, add them to the scenario anyways. It makes it easier for a new developer (think of someone new to production support) to understand what’s happening with an interface, when they can see a consistent flow of the interface sender agreement to receiver agreement on all interfaces in a landscape. I know from working with working with soap, it’s kind of nice being able to grab the wsdl from the sender agreement, even though that component is technically optional.

• Don’t force an interface to work- If you are configuring a determination or agreement and are not seeing what you expect from the drop down menu, it may be because you haven’t properly defined the SLD or IR. Don’t be lazy and select the interface from all namespaces or SWCVs just to make the interface work; go back and figure out why its not dropping down on the drop down box and correct it.

Establishing and adhering to a well thought-out and consistent naming convention can save you a lot of time during the support of your SAP PI interfaces.  In Part II of this blog, I will discuss naming conventions in SAP PI’s Enterprise Service Repository (ESR).

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.

Description:

This document gives step-by-step instructions on how to install, setup, and configure the JMS adapter to communicate with Oracle AQ Messaging.  Oracle AQ and the SAP XI adapter are not compatible as delivered by SAP and Oracle.

DataXstream adapter software was developed to bridge the incompatibilities between the SAP JMS adapter and Oracle AQ.

SAP Exchange Infrastructure – JMS for Oracle AQ Setup Instructions