Troubleshooting the Services Registry
Recently I set up the services registry for PI 7.1 EHP1 for a client of ours. Although it seemed like it would be a simple process, I ran into a 401 authorization issue and another issue where web services were not publishing to the services registry. Looking online there are a lot of people who ran into the same issues as I did, so I am providing, here, the steps to perform if your services registry isn’t working.
Changed RFC Structure Not Propagating to XI/PI Runtime
In support of an synchronous XI interface (SOAP->XI->RFC), I changed the underlying structure of one of the RFC parameters. I appended some fields to the end of a return structure in ECC. I re-imported the RFC meta data to the Integration Repository as always and mapped the fields accordingly. When I executed the interface, the fields that I added did NOT appear in the XML. This is because the XI runtime cache did not have the updated metadata for the RFC.
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
SAP Standard Sale Area Cross Reference For Inbound IDOC Processing
Cross Reference To SAP Sales Area From External Customer Number – SAP EDSDC Table
If you have ever converted an external file into a SAP Sales Document IDOC (ex: ORDERS05) you may have hard coded the E1EDK14 segments of the IDOC which specify Sales Area and order type for the SAP Sales Document. However, these segments are not required if you populate the E1EDKA1-LIFNR segment of the IDOC with the External Customer Number and populate the EDSDC table with the Sales Area and Order Type for the customer. Your SAP system contains a standard utility that converts the External Customer Number to the Sales Area values and Order Type value contained in this table.
Sales Area Cross Reference From IDOCs ORDERS05 and DELFOR02
This utility is available in the standard SAP package to convert External Customer Number to SAP Sales Area when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems. It eliminates the need to add E1EDK14 segments to the IDOC as it populates the Sales Organization, Distribution Channel, Division, and Sales Document Type using the entries in the EDSDC table which is populated using transaction VOE2. In order for this process to work, you must have the Customers External number populated in the E1EDKA1-LIFNR field of the IDOC where E1EDKA1-PARVW is ‘AG’ and the EDPAR Customer Conversion table set up to convert the Customer External number to the SAP Customer number. See my blog ‘SAP EDPAR Table – External Customer Number cross reference to SAP Customer Number’ for instructions on the External Customer Conversion. By properly doing this, the standard SAP function module will use the EDSDC table to convert the External Customer Number to the SAP Sales Area and Document Type. The following instructions will explain how to populate the inbound IDOC and the EDSDC table.
SAP Standard Customer Cross Reference For Inbound IDOC Processing
Converting External Customer Number To Internal Customer Number – SAP EDPAR Table
Have you ever had a project where you are converting a customer file into an SAP Sales Document IDOC (ex: ORDERS05) and the customer file contains their Internal Customer Number? So you need to determine what the SAP Customer Number will be on the IDOC. If you are not familiar with the SAP interface process you may hardcode the SAP Customer Number or create external tables in your third party mapping software to accomplish this conversion process. However, this involves customer specific logic or updating the tables with your SAP Customer Numbers and having a process to maintain this table as new SAP Customer Numbers are created. There is a much easier way to perform this conversion with no additional coding as it is a standard SAP utility.
Customer Conversion For IDOCS ORDERS05 and DELFOR02
This utility is available in the standard SAP package to convert External Customer Numbers to SAP Customer numbers (Sold-To, Ship-To, etc.) when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems. When working with data that will be imported into SAP via IDOC format the data usually contain your customers external sold-to and ship-to numbers and not the associated SAP customer numbers. Therefore, you would need to convert this External Customer Number to your internal SAP Customer Number. Instead of creating cross-reference tables or conversion routines in your third-party translation software you can populate the E1EDKA1-LIFNR field of the inbound IDOC with the External Customer Number and use transaction VOE4 to populate the EDPAR table. By properly doing this, the standard SAP function module will use the EDPAR table values to convert the External Customer Number to the SAP Customer number. The following instructions will explain how to populate the inbound IDOC and the EDPAR table.
SAP TechEd 09 Demo Jam Liveblog Recap
This blog is a recap of the liveblog of the SAP TechEd 09 conference Demo Jam. To read in chronological order, start from the bottom and work your way up.
SAP TechEd 09 Keynote Address Liveblog
Liveblogging SAP TechEd 09
Are you stuck in your cube while Bob from BASIS is heading to SAP TechEd 09 in sunny Phoenix? Are you afraid that you’ll miss out on all the sun and fun? While we can’t send the sun, we’ll try to bring you the fun. DataXstream will be liveblogging at SAP TechEd 09.
Head over to live.dataxstream.com on Tuesday, October 13, 2009 to get up to second updates from the show. We will be getting our liveblog on starting at 8am PDT (that’s 11am for you right-coasters) for the general keynote session. We’ll also be liveblogging from SAP TechEd 09 Demo Jam at 8pm PDT on Tuesday. The Demo Jam promises to be a great time, so plan to join us online after you put the kiddies to bed!
This is our first foray into liveblogging. Hopefully it will go off without too many technical glitches. We hope you’ll enjoy following the events with us!
Turn any SAP remote-enabled function module into a Web Service – Part 1
It still amazes me that not a lot of developers know that you can turn any existing SAP remote enable function module into a Web Service. It may sound like a challenging task, but it is just one of those things that you either know how to do it or you don’t. And to know how to do it only takes 15min to understand.
I have broken this down into 2 blogs Part 1 will show how to create the simple structured web service Part 2 will show how to configure and test the web service using SOAMANAGER and WSNAV
Allow Additional Mapping Types in SAP XI/PI
SAP PI is a powerful integration engine that allows developers a variety of methods for implementing transformation logic. As a long-time ABAP developer, one of my favorite methods to implement transformation logic is using ABAP. This transformation option is not enabled in SAP XI/PI out of the box. While information regarding how to enable ABAP transformations can be found in SAP help, I have found it easier to have step-by-step instructions.
Fun With SAP PI Message-Mapping
My previous post discussed the “hidden” menu in the SAP PI message mapping tool that can only be unlocked by pressing <Ctrl> + <Shift> while right clicking in the data flow editor area. Hands down, the best feature of this menu is the import/export functionality. I have no idea why the SAP developers buried such a useful feature in such a hard-to-find menu. Whatever the reason, now that we know that we can import and export message mappings, we can exploit this fact to make our map-developing lives easier.
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! Read more
