Re-Usable frame work in XI

After getting close to the production phase of XI implementation for a leading UK based client I would like to share some of the useful real time design and implementation practices to the XI world.

The project basically consists of Idoc-File and File-Idoc interfaces. Our team has already written many blogs on the generic approach and sample codes that can be re-used for any file to Idoc scenarios. Since different people wrote different weblogs it didnot convey the BIG PICTURE in a right way.I tried to fit it here.

Approach in nutshell for File to Idoc scenarios:
1.SAP XI IN ACTION gives you high level overview about the approach.
2.Configure the generic file adapter, which will read any CSV file into XI using just one communication channel for 80 interfaces. It is very useful as it has cut down the complications of configuring 80 file adapters in development system and QA systems (remember that we need to re-configure the adapters again in QA systems with appropriate meta data). I observed that there was no much performance bottlenecks due to this configuration and moreover it was really useful.
Configuring Generic Sender File CC Adapter provides more info about the same. We have one generic message interface for all the 80 interfaces, which reads any CSV file. It concludes that we have only one sender agreement in the ID for all 80 interfaces, which cuts down the number of configuration objects.
We created all the generic objects in a single namespace in the IR, which is re-used by 80 interfaces which helped us to cut down the maintenance effort by allowing us to change the data types, message types, message interfaces globally. We also created a generic scenario in the ID that contains all the generic adapter configurations and receiver agreements which is very helpful for synchronizing the development life cycle very effectively.
3.Route the generic file structure to the interface specific BPM.This can be done using the content based routing in the ID using the filename of the file that has been read.
4.Validate the generic file structure whether it conforms to the interface specific standards using java mapping.We use a interface specific java validation program which takes the generic structure and validates if the mandatory fields are present, text fields are coming with quotes, date formats are proper, mandatory segments are present etc. Validating the file using a java mapping will provide more control for handling exceptions than writing modules at the file adapter level. It is pretty irritating to provide the configuration for every interface and specifying the fields at the adapter level .I suggest this approach as it is benificaial for ease of alerting or triggering re-jection e-mails if the validation fails and the code being generic adds more flexibility and strong coupling during testing.
It is divided into 3 sections :
a.BaseValidate.java: Invoked by the interface specific java-mapping program that takes the interface specific structure in a vector and performs validation as specified in the vector.
b. Hierarchy.Java: Generic vector object that takes the validation requirements for all interfaces in the same format.
c. InterfaceSpecificValidate.java: It is the actual java-mapping program, which is modified by every interface for providing interface specific validation requirements and structure (XSD) for validation.
We have compiled the jar file comprising BaseValidate.Java and Hirearchy.Java and corresponding class files in a generic SWCV and created a usage dependency wherever the interfaces accessed the base classes. This approach has saved lot of time when we did lot of changes in base validation code through out the development time , compiled it and uploaded into imported archive globally and changes are reflected in every interface.
Confusing! Isn’t it? Have a look at the blogs given below.
Generic Approach for Validating Incoming Flat File in SAP XI – Part 1
Generic Approach for Validating Incoming Flat File in SAP XI – Part II
5.Transform the generic structure to hierarchical i.e symmetrical to Idoc structure.
This was most complex part of the implementation experience to transform the generic flat file structure. Initially it almost looked impossible to convert the row format to complex nested structure format. Indeed after a little effort I found out that is not impossible to transform the generic format to complex format but I can write a re-usable code which can be just used by all the interfaces by just specifying the interface specific XSD format and relation through a vector template.
It is indeed very trickiest and challenging part that gave me a great pleasure of doing it. Once we achieved this validation mapping is done successfully on the same idea and was really useful for solving the nightmare of any developer to create 80 complex file adapter configurations and writing 80 different validations mapping programs or writing 80 different modules for validating all interfaces.
It has 3 sections :
a.GenToHierMap.java : Invoked by the interface specific java mapping program that takes the complex hierarchal structure in a vector and builds the hierarchical XML.
b.Relation.java : Generic vector object that is used by Interface specific java mapping program for passing the interface specific structure to GenToHierMap.java.
c.Interface Specific GentoHierMap.java : This java program provides the XSD format in a vector required for building the interface specific XML i.e symmetrical to idoc structure.
Dividing the code into 3 sections provides ease of re-usability across all interfaces, which in turn abstracts the developer from knowing the unnecessary details and it is very useful in Onsite-Offshore model. Offshore team just need to know their interface structure and base class name for invoking it and they need not bother about the actual implementation of the base class which will controls the accidental modification and provides a great thorough put in testing and consistent behavior across all the interfaces.
Convert any flat file to any Idoc-Java Mapping provides the sample interface code, base code and vector structure for transforming generic structure to hierarchical structure.
6.Tranform intermediate hierarchical structure to Idoc Structure.It is just a one-to-one message mapping without any complication.
7.Configure the generic receiver idoc adapter under generic scenario, which pushes the idoc and use that from any interface specific scenario.

The best part of the approach is the ease and flexibility of re-usable code that can be used by any XI’Tian to implement any project involving idoc and file interfaces in a simple and nice way. I depicted the approach for file to Idoc scenarios and the same can be applied vice versa with slight modifications.

Note: Here I assumed that there is only one file server sending the files and all the files have to be routed and Idoc’s are posted to a single SAP system. If we need to deal with multiple file servers and SAP system then we need to replicate the generic adapters accordingly.