Generic interaction layer for business transactions
The component for business transactions is BT, you can see it in GENIL_MODEL_EDITOR :
The object table contains all the Bol objects of the component :
First column is the Bol name of the object, the second one is the name of business transaction subobject (as defined in table CRMC_OBJECTS).
Third column is the type of Object :
A Root Object
B Access Object
C Dependent Object
D Search Object
E Search Result Object
F View Object
G Dynamic Search Object
X Abstract Modeling Object
Then there are two structures name, one for attributes of the object and one for the key (most of the time only a GUID).
A read only flag defined if the object can be modify or not.
The handler class define the runtime class for the object, but most of the time the field is empty and the name of the class is derived from the object name (we will see how later).
The flag WS_ENABLED defines if you can use this object to create web services with the wizard.
And the last columns are used to manage switch IDs.
The model table contains all the relationships between these objetcs :
So we have the name of the first object, relationship name and name of the linked object.
Two fields for cardinality define how many relationships you can have between objects, if the relationship is mandatory (1 – 1) or unique (0 – 1).
Type of relation :
A Association : Binds child objects to a root object. Only access and dependent objects can
B Composite : Like an aggregation, but composed child objects must always exist.
C Aggregation : Link between any kind of objects. Can also be defined across components with
root or access object as target.
The component name is the component from which the linked object it taken (mostly BT except for some associations).
Flag STOREL indicates wether the relation is a static one,
The runtime class for the component is CL_CRM_INTLAY_BTIL, it is called for instance to read orders, maintain orders, execute query.
Then there is a runclass defined for each object, as we saw it can be defined in the object table or not, let’s see how the system find the right class for each objecct :
Class CL_CRM_OBJ_FACTORY_BTIL is used to determine the runtime instance for an Object :
- First the system try to find an entry in the customer objects table : CRMC_OBJ_BTIL_C
- If nothing is found the standard table CRMC_OBJ_BTIL is read
- In case an entry is found in any of these tables the name of the class if obtained by adding _RUN_BTIL after the Handler class name defined in the table.
- If there is no entry in tables the class name is the concatenation of : ‘CL_CRM’ <INTOBJ_NAME> ‘_RUN_BTIL’, where <INTOBJ_NAME> is the name of BOL object without the 2 first characters, for instance BTOrder become ORDER.
Read an order
This is what is called in order to read an order from the GENIL :
- CL_CRM_INTLAY_BTIL->GET_DATA, call by the method READ_ORDERS, this is where the CRM_ORDER_READ function module is called, requesting the objects needed.
- Then the READ_ATTRIBUTES method for the root object runtime instance (CL_CRM_ORDER_RUN_BT) is called to fill attributes of the bol object.
- Then the children are read using relationships and runtime instances for the requested objects (recursively), examples : CL_CRM_DATESSET_RUN_BTIL->READ_ATTRIBUTES.
Modify an order
This is what is called in order to modify an order into the GENIL :
- Then runtime instance of Root object CL_CRM_ORDER_RUN_BTIL->MAINTAIN_ATTRIBUTES
- Then the children runtime instances (recursively), for instance : CL_CRM_ADMINH_RUN_BTIL->MAINTAIN_ATTRIBUTES
When using a dynamic search object :
- Then runtime instance defined for the bol object of the query, for instance CL_CRM_QSLSORD_RUN_BTIL->GET_DYNAMIC_QUERY_RESULT.
In order to execute a method of the bol object :
- CL_CRM_BTIL-> EXECUTE_OBJECT_METHOD
- Runtime instance of the object, for instance CL_CRM_PARTNERSET_RUN_BTIL->(method_name)
It’s easy to extend the genil for business transaction using the customizing :
Extend Model for Business Transactions with New Nodes :
In this activity, you can exend the object model for business transactions with additional nodes. All nodes used in business transactions must be available in this table.
You can also change existing nodes if you want for instance to change the attributes structure in order to add your own attributes (useful for dynamic querie).
When using AET entries are added automatically.
Extend Model for Business Transactions with New Relations :
In this activity, you can exend the object model for business transactions with additional relations. All relations used in business transactions must be available in this table.
You can also add object relations that are derived from Customizing entries. For example, you have created your own partner function <xxxxxx> and would like to read all partners with this partner function. To do this, you create a relation BTPartner_<xxxxxx>, it’s the same for Date type as well.
When using AET entries are added automatically.
Define Custom Handler Classes for Business Transaction Model :
In this activity, you specify the handler classes you want to use for nodes you have added to the business transaction model, or the customer handler classes you want to use for existing nodes in order to replace standard behaviour.
To do this, you specify the name of the relevant BOL object (node) and the name of the handler class. Handler classes you create should inherit the methods from the SAP handler class so that you only need to program the delta required. The settings you make override the handler classes used as standard and therefore affect the standard behavior of the objects.
Your class name should end with ‘_RUN_BTIL’, but you must not put that in the Handler class name defines in the customer objects table, for instance if your class name is ZCL_CRM_ADMINH_RUN_BTIL, just put ZCL_CRM_ADMINH in the table.