In our SAP NW CEO exercises or project experiences we would have come across the transaction SXI_CACHE and used it extensively without even really understanding exactly what it is all about and would have even faced weird errors. Typically in real time environment when people are placed in XI projects in which they have to swim themselves tend to get confused and lost in SAP help .I always like to explore the ABAP stack of SAP XI and the way it is built to get familiarity with SAP XI like any other SAP product. I don’t have any aversion towards java but due to the limitation of my experience in JAVA I could not explore much on J2EE stack.
In this blog , I will try to describe the actual technical functionality of the black box. I don’t know whether it is right or wrong but I prefer to define the terms the way I understand.
Cache : A memory area where frequently accessed data can be stored for rapid access.
SXI_CACHE: A memory area where the information about the design and configuration objects of the J2EE stack is stored in temporary ABAP data dictionary tables. The integration engine uses it at the run time for accessing the appropriate design and configuration objects of J2EE stack.
Firstly let me describe the essential difference between two types of cache refresh:
1.Delta Cache Refresh: Any new objects that have been created/modified during the design/configuration activities are inserted into the temporary database tables when we use delta cache refresh option.
2.Full Cache Refresh: All entries in temporary cache tables are deleted and a background program for inserting the complete information about all the design/configuration objects.
When we execute cache refresh explicitly from SXI_CACHE it tries to retrieve the meta data of design and configuration objects using the FM SAI_CACHE3_REFRESH_HTTP which dumps the data in XML format and SAX parser API’s are used for parsing the XML dumps and storing it in the temporary cache tables.FM SWF_XI_BPM_CACHE_REFRESH is used for refreshing workflows (ccBPM’s).
CL_AI_CACHE_DIR is the ABAP Object, which is executed by the integration engine to pick the metadata information about design/configuration objects of the J2EE stack. REFRESH_CACHE is the crucial method, which has the implementation logic for performing the cache refresh.
Some of the important cache system tables used by SXI_CACHE:
1. TRD_RELATION- Meta Data for Receiver Determination
2. TRD_RULE- Meta Data for condition based routing
3. TRD_NAMESPACE-Meta Data for XPATH rules
4. TRD_EXTRACTOR- Meta Data for containers used in ccBPM
5. SMPPREL3-Meta Data for Mapping runtime
6. SMPPMAP3- Meta Data for Mapping runtime
7. SMPPSPLIT- Meta Data for Mapping runtime
8. SXI_SWCV_LAYER- Meta Data for SWCV
9. SSRVBINDING- Meta Data for Service Bindings
10. SSRVPARTY- Meta Data for Parties
11. SSRVSERVICE- Meta Data for Services, Party Identifiers for a Service
12. SSRVCHANNEL- Meta Data for Communication Channels
13. SWFXICACHE- Meta Data for ccBPM’s
14. SWFXICLOG- Meta Data for ccBPM message logs
15. SWFXIOBJS- Cache: Objects of a Process Definition (Proxy, CRL..)
Let me also explain the role of SXI_CACHE when creating or modifying new integration processes, which might be useful when tracing the weird errors in ccBPM’s.
When the new integration processes are created and configured in the integrated builder and activated, sxi_cache will retrieve the metadata of process definitions and signatures which will create the workflows and proxies (ABAP Objects) respectively. The communication between the ccBPM’s and the integration pipeline happens through this ABAP objects that are nothing but proxies, registered as process checkpoint events of the workflow.
For Ex : MI_WEBLOG_ABS1 interface is generated by sxi_cache as ZXI_PROXY_ MI_WEBLOG_ABS1_0001 ABAP object which can be viewed using SE24 editor and they are registered as events of the workflow which can be viewed using SWE2 transaction.
I felt this understanding will be definitely useful as it helped me in troubleshooting the problems like container definitions/conditions are not found etc when importing integration processes from DEV to QA and all the ccBPM’s are with 99 status. I have debugged the sxi_cache for trouble shooting the problems in our QA box and ended up in understanding the runtime behaviour of sxi_cache. After the base understanding, I finally found out that the root cause of those errors is due to the missing proxies. SXI_CACHE was not able to generate proxies automatically when exporting objects from development to QA box. Finally with the help of SAP, we found out a system program, which can be used for generating the proxies explicitly through the program. Once the report is executed and ccBPM’s are re-activated in the SXI_CACHE the status of the ccBPM’S has been changed to 0.
This information might be useful when you really want to understand the way XI works before using XI as a black box with features and trouble shooting weird problems at the runtime that provoked me for blogging the same.
11 Comments
