Skip to Content
Did you see HTML editor in Integration Repository/Directory? I am sure that it is not a new one. If not, this blog is describing the one of the feature available in XI on documentation and it also describes how to use it, how much useful it may be.

As part of huge XI implementation project, handling hundreds of interfaces, it is very difficult to keep track of attributes of all the objects like Data Type/Message Type/Message Interfaces/Mappings etc. Let me define attributes now. The attributes are nothing but, Name of the Object, Descriptions about the object, Author of the object, Date Created, Reason for the Object, Revision history etc.

It is very important that there should be proper documentation for each object. Otherwise if any changes needs to be done in future and it is very tedious task for the people who are not developed the objects. Whenever any changes are done it should be documented properly with providing Date changed, Reason for the change, Descriptions about the changes etc. So like change history of ABAP programs/or any Java Programs are maintained, we can maintain this developer log for each object.

Here is step-by-step procedure to achieve the same
Go to View from Menu->Documentation

image

Click on Create Button
image

Click on Dropdown Box
image

Here enter the description , details, date,modification log etc

image

After entering, save it . Then it will be like this
image

Activate the object. and then look into the object by View->Documentation
image

This can be done in object level or namespace level or software component level.

Real-time Best Practices –where it is prefer to use
1.Software Component:
• Describe Integration Scenario with Source and Target System details with brief- i.e functionality.
• Describe different namespaces used and purpose
• Name of the Imported Objects and the purpose

2.Mapping:
• Mapping functionality and Logic i.e. pseudo code
• User defined functions and purpose
• Validations if any
• Enhancement/modification log and the reason.
• If we use Java Mapping, many places we will not put .java file in the imported archive for security or other reasons. So it is better to explain the entire logic/pseudo code to understand the implementation.

3. Integration Process:
• If the scenario contains very complex business process, then it is required if it is explained in the documentation. It can be good if flowchart kind of description is given here.

4. In the Integration Directory
It is good practice to describe the flow of the message processing by describing sequence of XI pipeline steps.
-Sender Agreement
-Receiver Determination
-Interface Determination/mapping
-Receiver Agreement
If the documentation describes all the sequence of steps executed in the multiple receivers/complex scenarios, it can be very easy to handle the interfaces for any successor consultant.

This feature may be useful in any of the future XI implementation project.

To report this post you need to login first.

8 Comments

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

  1. Michal Krawczyk
    Hi Krishna,

    maybe try adding some
    “best practices” on creating HTML
    documentaiton:
    – which object do you document
    in real pojects
    – what do you describe (funtionality, mapping code?)
    or some hidden tips/tricks
    on creating it as the “html docu” topic is rather a little bit
    too easy to be described alone.

    what do you think ?

    Regards,
    michal

    (0) 
    1. Krishna Moorthy P Post author
      Hi Michal,

      Yes you are right. This is just an update for this html editor. This is just an dummy e.g I took here
      But in real project – I have added for the Mapping objects- I think it is required here.
      1) Mapping logic and functionality
      2) If any enhancement log, and why
      3) Any validation rules

      Because some enhancement comes, and if the developer is not there, then it is very difficult to track what is happening provided if you many user defined functions.
      And it is best practice to add in the SWCV to describe about specific scenarios i.e namespacewise.

      Thanks for the comment, and i will update these in the blog.
      Regards,
      Krishna

      (0) 
        1. Hi,

          Putting interface documentation into XI may sound beneficial but indeed is of no use as the the consumers of the interface will not be able to use the html documentation maintained with in XI.

          ESR is the way to go. Putting all the service description like
          1. Functionality
          2. Operation
          3. Sample Code
          4. Examples
          into ESR will enable the consumers of the interface to know more about the interface by browsing ESR(Enterprise service repositoy).

          SAP is going big time with ESR. Eventually one would be able to publish all the interfaces in XI to ESR, put in the corresponding descriptions. THis way both developers and the business users will get to kmow more about the interface.

          cheers,
          Naveen

          (0) 
          1. Krishna Moorthy P Post author
            Hi Naveen,

            Yes, but my intention was for XI developers/support people.
            Thanks for the very useful info. I  heard about ESR. But I am not aware of how to use etc. Because i thought it is only used for repository for the java codes.  
            I may disturb you on this topic after sometime!!!

            Thanks a lot
            Regards
            Moorthy

            (0) 
  2. Piyush Srivastava
    Hi

    Good Job man!!

    But when i tried this with essage Interface i see only “Use” option, and when tried with Message type found only “Definition”, “Structure”,”Use”, i am at SP14 right now.

    and i can find the Doumentation in view menu of SWCV as you suggested in Blog.

    any comments on this.

    Thanks

    Piyush

    (0) 
  3. Martin de Villiers
    Hi,

    Would it be possible to export the documentation created in the Object Editor as a whole, covering the implemented scenario?  For example, to release all the individual documentation parts (data type, message type, mapping, etc.) as a whole in order to create a Technical Design Specification showing all relationships.

    Regards,
    Martin

    (0) 
  4. Hi Krishna

    This is a good foundation.

    Do you have an more info on linking to external documentation through a hyperlink?

    Thanks

    Simon

    (0) 

Leave a Reply