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! Isnt 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 XITian 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 Idocs 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.
thx for this ideas share. We have done something similar, but only in ABAP on R/3. We also worked with many CSV files in the "interface module", behind which there were some customizing tables and some dynamic generated dynpros.
Your "implemetion steps" description gives me more ideas, how to combine ours already gained experience with interfaces on R/3 and XI.
If somebody would ask me, I would suggest to use a traditional mapping engine, instead. It solfes all your validation, translation and hierachy requirmeents.
This architecture has cut down lot of efforts and it would have definetly complicated the matters for this and may be I didnot detail the real complexity of the mapping but in the real time am sure this approach will be very beneficial.
Configuring Generic Sender File CC Adapter
The effort taken in writing a java function to parse the fields (capable of detecting qualifiers), and split it into fields to make those fields mappable (which cannot be generic) is more than the effort in just simply giving the settings file content conversion of file adapter.
I would rather give some 10 parameters in File Adapter settings rather than coding 50 lines! I belive, making anything generic and difficult, which is already simpler is not needed.
Can you go through the blog Re-Usable frame work in XI
It is definetly generic and definetly very very very easy.
Let me know if we can talk in e-mail for knowing further.I bet you will appreciate the approach.
Configuring Generic Sender File CC Adapter
This design seems easy and sleek from a developer point of view. Yes, it saves time in setting up the adapter parameters, reduces number of communication channels etc.
But, the design also demands knowledge of java programming. What happens when your client starts owning the system. What if business demands a change in one file format. Are they going to train their team for java development? May be it would have been easier for them to handle if you had maintained individual communication channels.
There is no much complexity.
Can you see the interface specific java class?
It is merely a template.You can easily change the fields with just core java.
I myself do not have much of java knowledge but yet found out to be relatively simple.
can you see the blog Re-Usable frame work in XI
MRIGenToHierMap.java is only thing which gets modified for every interface.Iam sure you will agree that it is not very complex job.
Convert any flat file to any Idoc-Java Mapping
>> MRIGenToHierMap.java is only thing which gets modified for every interface
If I can change the values inside the 'generic' java program, compile and export it as jar, then import it in XI and do a scenario which you feel easy, what dificulity will anyone face in just changing the parameters in CC which does not require any code/compilation/export/import?
This again in the mentioned blog Convert any flat file to any Idoc-Java Mapping is not generic!
This appraoch is not used to just escaping the parameters at file adapter .There are lot more advantages to it.I cannot share the entire info in a small blog.If you can mail me at my id...we can talk in detail..
I for one, applaud your efforts. While I have not read through your solution, having struggled with the gross inadequacies of the file adapter for the past 3 months, anything that minimizes the configuration effort and file content conversion effort is a good thing. For those that think that Java is not a good thing for your client, I point out that good Java programmers are cheap and readily available as opposed to your expensive SAP programmers ¡V although I realize that you are only trying to protect your closed shop. May I say ¡V wake up and smell the coffee ƒº? Anyway, good job, I look forward to going through your solution when I have the time.
good blog- but for fixed length files (as opposed to delimited) is there any such generic approach possible.
I couldnt think of any