Skip to Content
Steps to Consider in Developing Content ( Business Package ) in XI30 by Partners

Introduction: Exchange Infrastructure 3.0 offers open and flexible development environment for partners to develop business content for customers in various business areas of A2A and B2B Integration. Apart from providing the Integration Technology, SAP also provides XI content for various SAP applications and welcomes partners to develop content for different A2A and B2B Applications. The information provided below will give a head start to any partner who are interested in developing the content using Exchange Infrastructure 3.0.

The details provided here is not a Methodology to follow or a Best Practice because, the design to develop Business Content varies in each case. The content must be designed focusing the customer Business Processes, with very minimal changes allowed after implementing the Content. A customer developing business scenarios in XI30 is different than implementing a Business Scenario developed by a partner.

The steps described below are important and based upon the author’s project experience.

1. System Landscape Directory.
2. Integration Repository.
3. Integration Directory.
4. Documentation.
5. Content Certification by SAP ICC.

1. System Landscape Directory: SLD plays a major role in defining the objects like Product, Product Version, Software Component and Software Component Version etc.

· Product Name and Version must be clearly defined so that the customer can easily understand who developed the business package. For example a combination of the Vendor Name and the applications involved is a good starting point. The version number must be carefully defined so that the partner can follow Version Management in integration Repository where the objects are shipped consistently as part of the Product.

· Software Component Name and Version is like a shipment unit for design objects in Integration Repository. The names can also be in consistent with the Product name and Version. If the business scenarios requires dependency of an another Software Component, for the design objects to be reused, make sure to define the parent component first and create a dependency of the parent to the child Software Component.

· Define the necessary Business Systems and Technical Systems in SLD with appropriate names required for the Business Scenarios to be used later in the Integration Configuration.

2. Integration Repository: Once the Software Component is imported into the Integration Repository from SLD, the Namespace has to be defined clearly. Repository Namespaces are used to avoid naming conflicts where the objects defined can be unique. Since the namespaces can be any constant value, follow the usual convention. For Ex: “http://vendorname/xi/name“ or “urn: vendorname/xi/name”. Namespaces can be one to many based upon the number and complexity of the business scenarios.

· Interface Objects: Data Types/Message Types / Message Interface Objects: Follow a well defined naming standards which is clear to the customer implementing the business scenarios. For Ex: Date Type and Message Type can have the similar format. For Message Interfaces, you have an option to add the attributes to the Interface Name. For ex: “InterfaceName_Inb_Async”. In case of Abstract Interfaces, adding attributes to the interface name differentiates them clearly with non Abstract Interfaces. For Ex: “InterfaceName_Abs_Async”. If the scenario involves importing external schemas ( XSD, WSDL etc.) as an external definitions, check all the Namespaces character length, as there is a maximum 60 char limitation for Namespaces in the Integration Repository.

· Mapping Objects: Message Mapping and Interface Mapping names can be unique based upon the business scenario. In Message Mapping programs, try to avoid using constant values for target field mapping. Also if you are planning to use look ups for DB, RFC or SOAP at the mapping step level, try to avoid them if possible as the lookups require the configuration objects names ( like Business System Name, Communication Channel Names etc.) in the user defined function which are different in each customer case. An alternative to this is to use Value Mapping Table functionality.

· Integration Scenarios and Integration Processes: Integration Scenario Objects have to be designed in order for the customer to be able to import the Repository Objects into the Integration Directory and set up the necessary Configuration Objects. Follow the guidelines described at http://help.sap.com to model the Integration Scenarios. Set up the necessary actions and connectivity between the Sender and the Receiver. If there is a Business Process involved in the Integration Scenario, carefully define the steps in the BPM and assign the appropriate attributes in each step. The container variables and correlation objects, must be clearly defined so that the customer can easily understand the process steps defined in the BPM.

· Adapter Objects: If there is a possibility to create Communication Channel templates, provide those details at the design time, so that the customer who will be implementing the Business Scenarios can use these channel templates at the Configuration step.

3. Integration Directory: The customer implementing the business package will be working mainly in the Integration Directory to set up the necessary collaboration profile objects using the configuration wizard. Before creating the configuration objects, perform the necessary checks in SLD for Business Systems and import the objects into the Integration Directory. Also, if the communication channel types information is provided by the partner in the documentation, it is recommended to create the required communication channels in advance so that the other collaboration objects like sender/receiver agreements are created automatically by the wizard.

4. Documentation: Documentation for the delivered XI content is very helpful to the customers in implementing the business scenarios. Configuration Guides on how to deploy the XI content and implement the Business Scenarios must be well documented with all the details included. Provide screen shots wherever necessary so that the customer can implement the Business Scenario’s very easily . Partners developing the XI content must also provide support details to the customers.

5. Content Certification: Partners developing the content has to plan in advance at the design phase itself and schedule the testing part with the SAP certification team(SAP ICC), to test the XI content. In order to pass the certification successfully, the content must follow all the rules and requirements (Standards, Naming Conventions etc.) with Syntactical and Functional Correctness. Test Cases with the required documentation must also be provided to test the various business scenarios.

References:

· SAP Library: SAP Exchange Infrastructure Help.

· NW –XI-CNT 3.0 : Test Catalog for XI-Content-Certification ver-1.3

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Anonymous
    Hi,

    nice blog listing everything necessary in one place. However it should also be communicated SAP internally as i have worked with various SAP standard content packages and the quality differs quite a lot.

    regards
    Christine

    (0) 
    1. Prasad Illapani Post author
      Thanks Christine,

      I have mentioned this clearly in the weblog:
      “the design to develop Business Content varies in each case.”.

      I agree with you the content is different with in SAP for each application. Its the same with Partners too.

      Regards
      Prasad

      (0) 

Leave a Reply