The Adapter framework is the underlying technology supporting most of the XI adapters. The slide shows the internal architecture of the AF.
As a quick walkthrough of the slide, here is an explanation of the numbers present in the diagram:
1: Each specific adapter (developed either by SAP or a third-party) must comply with the JCA 1.0 specification (Java Connector Architecture). For instance, the adapter logic must have a system contract and application contract with the base J2EE engine.
2/3: Internally, each specific adapter is considered as a “module“ attached to the adapter framework module processor.
The module contains the logic specific to a given adapter. New modules can also be developed by the customer when there is a need for custom Java Code at the adapter level. The module is then called like a ‚user exit‘ and must be referenced explicitely in the communication channel configuration. Standard modules from SAP do not need to be referenced explicitely (with the exception of the SOAP adapter).
4: The adapter-specific configuration objects are accessed locally from the CPA Cache, which itself is derived from Integration Directory (central configuration). See the chapter on CPA-cache for more details.
5: The AF provides some administration services common for all adapters (ie monitoring and health check). Most of the administration features are accessible from the runtime workbench. However some AF administration is done in the J2EE Administrator tool directly . The adapter framework has its own persistence layer, which is in the database schema underlying the J2EE engine.
6: low-level technical utilities (threads, transaction management). Standard features of the J2EE engine are leveraged here.
7: logging API: the logging is consistent with the rest of the applications deployed in the J2EE Engine.
8: The message metadata is derived directly from the Integration Repository.
9: The Integration Repository also contains ‚adapter metadata‘. This is how the containers for the adapter-specific configuration are defined. This is also how 3rd parties can define such containers for additional adapters. The adapter metadata translates into adapter-specific configuration screens in the ID. It is consumed by the adapter framework at runtime.
The Adapter Framework resides on the SAP J2EE Engine 6.40. In the case of the JMS and JDBC adapters, the appropriate vendor-specific drivers must be deployed on the J2EE Engine in order to function properly.
Related Post
SAP XI connectivity
Syntax for Insert data into Table
You can go through entire syntax check here.
Check SAP SCRIPTS AND SMART FORMS BDC HERE COMPLETELY.
Learn object oriented approach of SAP ABAP HERE COMPLETELY.
ABAP ALE CONFIGURATION
BADI Complete Series and BAPI complete course
As a quick walkthrough of the slide, here is an explanation of the numbers present in the diagram:
1: Each specific adapter (developed either by SAP or a third-party) must comply with the JCA 1.0 specification (Java Connector Architecture). For instance, the adapter logic must have a system contract and application contract with the base J2EE engine.
2/3: Internally, each specific adapter is considered as a “module“ attached to the adapter framework module processor.
The module contains the logic specific to a given adapter. New modules can also be developed by the customer when there is a need for custom Java Code at the adapter level. The module is then called like a ‚user exit‘ and must be referenced explicitely in the communication channel configuration. Standard modules from SAP do not need to be referenced explicitely (with the exception of the SOAP adapter).
4: The adapter-specific configuration objects are accessed locally from the CPA Cache, which itself is derived from Integration Directory (central configuration). See the chapter on CPA-cache for more details.
5: The AF provides some administration services common for all adapters (ie monitoring and health check). Most of the administration features are accessible from the runtime workbench. However some AF administration is done in the J2EE Administrator tool directly . The adapter framework has its own persistence layer, which is in the database schema underlying the J2EE engine.
6: low-level technical utilities (threads, transaction management). Standard features of the J2EE engine are leveraged here.
7: logging API: the logging is consistent with the rest of the applications deployed in the J2EE Engine.
8: The message metadata is derived directly from the Integration Repository.
9: The Integration Repository also contains ‚adapter metadata‘. This is how the containers for the adapter-specific configuration are defined. This is also how 3rd parties can define such containers for additional adapters. The adapter metadata translates into adapter-specific configuration screens in the ID. It is consumed by the adapter framework at runtime.
The Adapter Framework resides on the SAP J2EE Engine 6.40. In the case of the JMS and JDBC adapters, the appropriate vendor-specific drivers must be deployed on the J2EE Engine in order to function properly.
Related PostSAP XI connectivity
Syntax for Insert data into Table
You can go through entire syntax check here.
Check SAP SCRIPTS AND SMART FORMS BDC HERE COMPLETELY.
Learn object oriented approach of SAP ABAP HERE COMPLETELY.
ABAP ALE CONFIGURATION
BADI Complete Series and BAPI complete course
No comments:
Post a Comment