What’s in a Naming Convention? Part II
In my last post, I discussed naming the naming convention that DataXstream recommends for SAP PI Integration Directory (ID) objects. I would like to say that I had a great DataXstream ESR-specific naming convention, however the SAP naming convention guide for PI 7.1 does the job perfectly. Here is the link to the PI 7.1 naming convention guide http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40a66d0e-fe5e-2c10-8a85-e418b59ab36a?QuickLink=index&overridelayout=true . I would like to point out some things that I feel most people miss, as well as some things that I think are particularly interesting.
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.
Using Native SQL in an ABAP Proxy
Recently, I was looking at a requirements document to build an interface to an external system that wants to query customer master data by the customer first name and last name. As I read this, there were a cacophony of thoughts, all demanding equal attention, racing through my head:
- How will I ever match the inbound interface parameter “Tom” with “TOM”, or “tom”?
- How will I ever match the inbound interface parameter “Smith” with “SMITH” or “smith”?
- The ABAP WHERE clause is not case-INsensitive.
- There could be hundreds of customers named Tom Smith.
- KNA1-NAME1 and KNA1-NAME2 are not indexed fields.
- And no, we are not storing any portion of either first or last name in an existing indexed field like SORTL.
- There are well over one million customers in the database.
- We have already decided to use PI for all interfaces.
- I will have to buy the BASIS team a case of beer to get them to agree to create indices on the fields KNA1-NAME1 and KNA1-NAME2 in a table with over one million records.
I arrived at the conclusion that I need a case-insensitive database query, along with database indices created for the fields KNA1-NAME1 and KNA1-NAME2.
But, what is a case-insensitive WHERE clause? A little research and help from colleagues revealed that many had gone before me, and this was nothing new. To implement a case-insensitive WHERE clause in ABAP, you simply needed to use the native SQL UPPER() construct. The database system that is being used is Microsoft SQL Server, but the UPPER() function and its syntax is similar across different database platforms. This seemed like an easy nut to crack. But, as I soon found out, I actually had a lot to learn. Read more
What’s in a Naming Convention?
It doesn’t take long for a PI implementation to become a complete mess if standards are not put in place before development occurs. Even among seasoned developers, opinions vary as to the best way to name and organize the IR (ESR) or ID (IB), depending on different backgrounds and previous project experience. In the next few blogs I would like to touch upon some of the best practices that we utilize in our implementations at DataXstream, which we have arrived at though our project experiences and discussion, both internally and with other middleware experts. Read more
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!
