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.

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