Beruflich Dokumente
Kultur Dokumente
Table of Contents
Introduction
Release Relevance
How to Use
How to Use at SAP
Definitions
Overview
Architecture
Basic parts
General services
GenIL customizing
Model service
Data container
Component development
Basics
Model definition - IF_GENIL_APPL_MODEL
Interaction Interface - IF_GENIL_APPL_INTLAY
Filter Relations
Additions
Simple object development
Basics
Model definition
A read-only object
A changeable object
Transactional parts
Additions
How to Use at Customer Site
Example
FAQ
Related Architecture
Responsible
Introduction
This page explains the basics on how to implement a GenIL component. If you have WEBCUIF 7.01 (EhP1) or later releases
installed, please check also the other how to guides regarding the GENIL_MODEL_EDITOR and the handler concept. Both
might ease your life implementing your component.
Release Relevance
This HowTo guide focuses on the functionality provided with WEBCUIF 7.0. It includes additions introduce with WEBCUIF 7.01 (EhP1). These are
marked accordingly.
How to Use
Overview
Architecture
Basic parts
The generic interaction layer consists of the following basic parts:
Core module: Provides the consumer interface of the generic interaction layer for uniform access to all offered business objects as
single point of entry. It translates and dispatches all requests for the components and collects the results afterwards.
Model service: Provides access to all meta data which describes the available business objects, their nodes, properties and relations.
The service is generally available and can be used by components as well as consumers of the generic interaction layer.
Data Container: The data container is a transport container for tree like data structures with an object oriented API. All business object
related data within the generic interaction layer is exchanged via data containers.
Simple Object Component: This is a special component to ease the implementation for a certain kind of business objects, so called
Simple Objects, see definition. It defines an additional set of customizing, a simple view on the data container, and a special
communication interface.
General services
GenIL customizing
Basic customizing
The basic customizing consists of two steps:
the definition of GenIL components and
the definition of GenIL component sets.
First we have to define components. The definition is done in maintenance view CRMV_GIL_COMP and consists of the component name, a short
description, and the name of the implementation class. The other parameters are for optional use and are of informational kind.
After the definition of components we can define a component set. An component set is an arbitrary set of components, which should be used
together by the generic interaction layer. One may want to use just all components, but will lead to an unnecessary high system load and is
usually not required. Also for testing purposes it is very helpful to define an own component set with a very limited set of components. The
component set definition is done in maintenance view CRMV_GIL_APPCOMP.
If a component set should also use the simple object component the component SO2 must be included in the definition.
It is also possible to use view cluster CRMVC_GIL_APPDEF to made all the definitions. The cluster arranges the single views in the correct
sequence and supports hierarchical dependencies.
Model service
How to understand the model term
One of the most important things in the concept of the generic interaction layer is the model definition, because most of the services and functions
rely only on the common model. When we talk about a model we think of an arbitrary set of business objects nodes with a well-defined set of
properties and relation between them. All this meta data together we call the model.
Since we are in an ABAP environment we have already a lot of meta data stored in the ABAP dictionary. We make use of this data and add only
the missing parts to our own model description.
The only thing defined by the GenIL is the data the model must include a how it has to be structured. The model data itself is not part of the GenIL
and is only managed by it during runtime.
The idea is that each component has its own model, describing the offered business objects, BO nodes, the relation between them, and relations
to BO nodes of other components. When a component is loaded this model information is derived and added to the runtime model. So the runtime
model is defined through the models of the loaded components.
Since WEBCUIF 7.01 you can create and maintain new GenIL models interactively using the GenIL Model Editor. See GenIL
Model Editor for further information
Model elements
Objects
As already mentioned a model consists of business objects structured in business object nodes and relations between them. The business object
nodes are subdivided into 3 kinds:
root objects,
access objects, and
dependent objects.
Further the GenIL concept introduces the service objects:
query service, and
dquery service.
Finally the special object kinds:
query result objects,
abstract object, and
view objects.
Depending on the object kind several actions for an object are allowed or prohibited. For instance, transactional behavior is only supported on root
objects, direct read access only for root and access objects, and so on.
The model of a component will always start with a root object (in case of a read-only component an access object may also make sense). This
root object is then related to one or more, in general, dependent objects. If the related objects are directly accessible (full key) they might be
defined as access objects. Of course the objects of a component can also have associations to root or access objects of other components.
Beside the object kind some more object properties are part of the object definition. The following table describes these fields in detail:
Legend: M: Mandatory, O: Optional, NA: not applicable
Field Name
Description
Root
Obj
Access
Obj
Dependent
Obj
Abstract
Obj
Query
Obj
OBJECT_KIND
M:
'A'
M: 'B'
M: 'C'
M: 'X'
M: 'D'
OBJECT_NAME
CREATE_STRUC
NA
NA
NA
NA
KEY_STRUC
NA
ATTR_STRUC
ROOT_OBJECT
MAPPING_TYPE
obsolete
NA
NA
NA
NA
NA
ATTR_NUMBER
NA
NA
NA
NA
NA
WS_ENABLED
If true, object enabled for the usage by the Web Service Tool
RESULT_OBJECT_NAME
NA
NA
NA
NA
DYN_MODIFY_CHECK
NA
NA
DYN_DELETE_CHECK
NA
NA
NO_ERRORS_ACCEPT
NA
NA
NO_INSTANCE_SAVE
Save for single root instances not supported. Save all or nothing.
NA
NA
NA
NA
DIR_CREATE_REQ
NA
NA
NA
NON_UNIQUE_PARENT
NA
NA
NA
NO_DIR_ROOT_DEL
NA
NA
NA
NA
DYN_CREATE_DATA
NA
NA
NA
SWITCH_ID
REACTION
SUPER_OBJECT
NA
NA
OBJECT_NAME_APP
HANDLER_CLASS
OPT_LOCK_SUPPORT
NA
NA
ASYNC_SAVE_SUPRT
NA
NA
MA_ENABLED
NA
NA
Methods
The declaration of object specific methods is only supported for Root Objects, Access Objects, Dependent Objects, and Abstract Objects.
Field Name
Description
Root Obj
Access Obj
Dependent Obj
Abstract Obj
METHOD_NAME
PARAM_STRUCT
RETURN_TYPE
Attributes
Attributes of an object are defined by the attribute structure given in the object definition. Here only additional properties can be defined. Please
note: If you do not fill the attributes table, it fill be filled automatically
with all attributes of the attribute structure later on. If you decide to fill the attributes table you have to fill it completely.
Field Name
Description
Root
Obj
Access
Obj
Dependent
Obj
Abstract
Obj
Query
Obj
Query
Result
Obj
Dynamic
Query
Obj
View
Obj
ATTRIBUTE_NAME
Name of attribute
NA
DEFAULT_PROP
NA
NA
NA
NA
PROP_IS_FINAL
NA
NA
NA
NA
USE_CONV_EXIT
NA
NA
NA
NA
NA
NA
NA
NA
STRUCT_INDEX
NA
NA
NA
NA
NA
NA
NA
NA
SWITCH_ID
NA
REACTION
NA
DYN_TEXT_SUPP
NA
NA
NA
Relations
We also distinguish 3 kinds of relations:
associations,
aggregations, and
compositions.
The allowed kind of a relation depends also on the related objects. For instance, the relation between a root object and a dependent object is
expected to be an aggregation or composition, but the relation between to root objects can only be an association.
In addition to the relation kind also the cardinalities of the source and the target object are part of the definition. These are mainly used to
distinguish between 1:1 and 1:n relation.
All relations are treated as unidirectional with a well defined source object (parent) and target object (child). The object kinds in the following table
are for the parent object.
Field Name
Description
Root
Obj
Access
Obj
Dependent
Obj
Abstract
Obj
Query
Obj
Query
Result
Obj
Dynamic
Query Obj
View
Obj
RELATION_NAME
NA
NA
NA
OBJECT_A
NA
NA
NA
CARD_A
NA
NA
NA
RELATION_KIND
Aggregation, Composition or
Association
NA
NA (should
be
association)
NA
OBJECT_B
NA
NA
NA
CARD_B
NA
M
(should
be 1)
NA
NA
DO_NOT_BUFFER
NA
NA
NA
NOT_WS_ENABLED
NA
NA
NA
SWITCH_ID
NA
NA
NA
REACTION
NA
NA
NA
FILTER_CLASS
NA
NA
NA
NA
USE_TAB_IF
NA
NA
NA
NA
NA
Data container
The data container is the universal transport media used in the generic interaction layer for transporting complex object structures. It provides not
only the ability of transporting data, it also provides an object orient API for accessing the data.
The data container it self is fully hidden and only its API is visible to the user. The API is in general structured into container objects and object
lists. Both appear in several specializations. Figure 4 shows the relationships between the different API interfaces.
In general the navigation through a data container starts from a root list object by selecting a specific list entry. From this object navigation is
possible via a relation, which results then in a new object list and so on.
The object list interfaces allow selecting entries or looping on the list. As a special feature the root list interface, each data container starts with,
allows also adding new container root objects.
All container object interfaces allow the access to the object attributes and additional data, like attribute properties. In addition to this simple object
functionality the container object allows navigation to dependent objects as well their creation. The very specific root object interface allows further
functions only defined for the container root.
Component development
In the following we explain step by step how to implement a component. Figure 5 shows the object model of the GenIL sample component. In the
following section we will always refer to this model.
However, this document does not include a sample coding. For this we refer to the corresponding sample implementation, which is part of the
WEBCUIF delivery. You can find the sample implementation with many comments in package CRM_GENIL_SAMPLE. The sample component is
represented by class CL_CRM_GENIL_SAMPLE_COMP.
Basics
A component of the generic interaction layer is represented as a global ABAP class, which inherits from the abstract base class
CL_CRM_GENIL_ABSTR_COMPONENT. From its base class it inherits two interfaces, one for the model retrieval, and one for the interaction
with the GenIL core, see Figure 6.
The base class provides a default implementation for each of the interface methods (in most cases an empty implementation). This means only
the needed methods have to be implemented/redefined.
Warning
Do not place initialization coding into these methods!
See Shared Memory
It is up to a component to decide how to keep the model information. It may be hard coded, but the recommended way is a system, control, or
customizing table. If no additional, component specific data is assigned with the model data the central model storage provided by the GenIL
Model Editor may be used.
Whatever is returned by the component is expected to be understood and handled by the component afterwards.
In our sample component the object properties table looks as in Table 1. The create structure name have to be given only for root objects. In
order to have a formal relation between queries and there result objects the result object type can be given.
The relations table for our [sample component model] would look like Table 2. As you can see the relation between the query object OrderQuery
and the root object Order is not modeled.
Object name
Object kind
Root
object
Key structure
Attribute structure
Create structure
Account
A (Root)
Account
CRMT_GENIL_OBJECT_GUID
GENILT_ACCOUNT_ATTR
GENILT_ACCOUNT_CREA
AccountAddress
X (Abstract)
Account
GENILT_ADDRESS_KEY
GENILT_ADDRESS_ATTR
AccountAddressDE
C
(Dependent)
Account
GENILT_ADDRESS_KEY
GENILT_ADDRESS_ATTR
AccountAddressUS
C
(Dependent)
Account
AccountQuery
D (Query)
Account
GENILT_ACCOUNT_ATTR
AdvOrderQuery
G (DQuery)
Account
CRMT_GENIL_ORDER_SEARCH
Order
A (Root)
Order
CRMT_GENIL_OBJECT_GUID
CRMT_GENIL_ORDER_ATTR
OrderItem
B (Access)
Order
CRMT_GENIL_OBJECT_GUID
CRMT_GENIL_ITEM_ATTR
OrderItemQuery
D (Query)
Order
CRMT_GENIL_ORDER_SEARCH
OrderItemQuery2
D (Query)
Order
CRMT_GENIL_ORDER_SEARCH
OrderItemSearchResult
E (QResult)
Order
CRMT_GENIL_OBJECT_GUID
CRMT_GENIL_ITEM_SEARCHRESULT
OrderItemShipmentData
C
(Dependent)
Order
CRMT_GENIL_SHIPMENT_KEY
CRMT_GENIL_SHIPMENT_ATTR
OrderPartner
C
(Dependent)
Order
CRMT_GENIL_PARTNER_KEY
CRMT_GENIL_PARTNER_ATTR
OrderQuery
D (Query)
Order
CRMT_GENIL_ORDER_CR
CRMT_GENIL_ORDER_SEARCH
Relation name
Object B
Cardinality A
Cardinality B
Relation kind
Account
AccountAddressRel
AccountAddress
C (1)
B (0..n)
C (Aggregation)
Order
OrderItemRel
OrderItem
C (1)
B (0..n)
C (Aggregation)
Order
OrderPartnerRel
OrderPartner
C (1)
B (0..n)
C (Aggregation)
OrderItem
OrderItemShipmentDataRel
OrderItemShipmentData
C (1)
C (1)
B (Composition)
OrderPartner
OrderAccountRel
Account
B (0..n)
C (1)
A (Association)
requested and fill in the data. This open concept allows further the pushing of additional data not directly requested.
It is possible to iterate on a root list to access included objects and to add new ones. From an objects it is possible to retrieve further object lists in
order to traverse the whole container.
It is important to distinguish between the container root object, as part of the container root list, and the object kind, defined as
root objects in the model. These are not necessarily the same!
Queries
We distinguish two kinds of query services:
The simple query, which allow to pass a set of query parameters which need to match either exactly or at least by some pattern.
The dynamic query, which allows to pass a dynamic set of parameters. It supports ranges and logical operators, like greater that or less
that, including and excluding options, and multiple options per search parameter.
All simple queries declared in the model have to be implemented in method GET_QUERY_RESULT. A query object defines a set of query or
search parameters by its attribute structure and returns a set of result objects, which are either root, access, or query result objects.
methods GET_QUERY_RESULT
importing
IV_QUERY_NAME
type
IT_PARAMETERS
type
IS_REQUEST_OBJECT type
IV_ROOT_LIST
type
CRMT_EXT_OBJ_NAME
CRMT_NAME_VALUE_PAIR_TAB
CRMT_REQUEST_OBJ
ref to IF_GENIL_CONT_ROOT_OBJECTLIST.
Since a component can define many query objects the first parameter IV_QUERY_NAME is the name of the query to be executed. The second
parameter IT_PARAMETERS is a table of name value pairs, which holds the parameters for the query. The third parameter IS_REQUEST_OBJ
is the request object structure. The fourth parameter IV_ROOT_LIST is a reference to an empty data container for the result list.
All dynamic queries in the model have to be implemented in method GET_DQUERY_RESULT. A dynamic query object defines a set of query or
parameters by its attribute structure. Additionally it defines for each parameter a set of supported options and operators. A query object defines a
set of query or search parameters by its attribute structure and returns a set of result objects, which are either root, access, or query result objects
.
The signature of the GET_QUERY_RESULT method is defined as follows:
methods GET_DYNAMIC_QUERY_RESULT
importing
IV_QUERY_NAME
type
IS_QUERY_PARAMETERS
type
IT_SELECTION_PARAMETERS type
IV_ROOT_LIST
type
CRMT_EXT_OBJ_NAME
GENILT_QUERY_PARAMETERS
GENILT_SELECTION_PARAMETER_TAB
ref to IF_GENIL_CONT_ROOT_OBJECTLIST .
Since a component can define many dynamic query objects the first parameter IV_QUERY_NAME is the name of the query to be executed. The
second parameter IS_QUERY_PARAMETERS is a structure which holds the values for the standard parameters. Standard parameters are:
MAX_HITS: Delimiter for the number of result objects to return. If it is 0, no limit is set.
MATCH_TYPE: No use.
DROP_SEL_PARAMS_ALLOWED:
SELECTION_HINTS:
The MAX_HITS parameter should be respected by each dynamic query for performance reasons. The other standard parameters or not always
relevant.
The third method parameter IT_SELECTION_PARAMETERS is a table with the query specific select options. Each line of the table holds to
following fields:
ATTR_NAME: Name of the selection parameter.
SIGN: Indicator whether the objects matching the given criteria should be included (I) in the result or excluded (E) from the result.
OPTION: Logical operator, like GT - greater than or LE - less equal. See fixed value of domain BAPIOPTION for reference.
LOW: Value to compare with, lower bound.
HIGH: Value to compare with, upper bound. This applies only for certain options.
The content of table IT_SELECTION_PARAMETERS is close to ABAP range tables in order to allow easy conversion to them.
The fourth method parameter IV_ROOT_LIST is a reference to an empty data container for the result list.
The basic implementation of both query methods looks pretty much the same and consists of the following steps:
1.
2.
3.
4.
For filling the data container you create for each direct result object an instance in the root list using method ADD_OBJECT and giving object
name and key. You receive an instance of the created container object and flag it as direct search result by calling method SET_QUERY_ROOT(
ABAP_TRUE ). Optional you can set the attributes of the object (mandatory for query result objects) and may add dependent objects.
Since the data container is a very open concept it is possible to return any additional data with the search result. However, it is
very dependent on the consumer if this is useful or not, so it should only be done if it is less or no additional effort. The minimal
requirement is to return the keys by creating instances on the container root list.
If you decide to return additional data you may pass the container to method GET_OBJECTS to do the job. The signatures do
match perfectly for this purpose.
Reading objects
The most central method in the interaction interface IF_GENIL_APPL_INTLAY is GET_OBJECTS. It can be used for any kind of read access to
the modeled objects of a component. The signature of the method is defined as follows:
methods GET_OBJECTS
importing
IT_REQUEST_OBJECT type CRMT_REQUEST_OBJ_TAB
IV_ROOT_LIST
type ref to IF_GENIL_CONT_ROOT_OBJECTLIST.
The first parameter IT_REQUEST_TAB is a table of request object entries. The second parameter IV_ROOT_LIST is a reference to a data
container. This data container is already pre-filled with objects and represents in this way also the set of objects to be read. According to this
technique it is necessary to traverse the whole container and to fill in the requested data.
The content of the pre-filled data container follows some fundamental rules:
The container root list contains always access objects (including root objects).
A container includes exactly one type of access object, but several instances may appear. Thus are in the root list.
It can include an arbitrary set of dependent object instances (dependent on the access object).
Dependent objects in 1:n relation may have only one representative/place holder.
Relation to other root or access objects appear as foreign relations. Here the term foreign is related to the actual data container.
According to the above rules other root or access objects must reside in another foreign data container.
According to this rules each request to a component is always split by access objects. Therefore the number of access
objects should be considered carefully to avoid a to high fragmentation of requests!
The basic algorithm for implementing the GET_OBJECTS method is shown in Figure 7. The Object handler lane represents a code block which
handles a certain object type. This could be a special instance or simply a method or function module.
Processing the root list, shown there, is a bit simpler then the process on the related object lists, shown in Figure 8. The major difference is that
objects of the root list have always a valid, where as the other list might just contain a place holder. The place holder is required since relation
them self are not represented by a separate API instance, so a related container object is always necessary. For relations know read so far the
related object are unknown, so no key could be given which leads to the place holder. In case of a 1:1 relation the place holder can be used by
simply assigning a valid key to it. In 1:N relations the place holder might be used as the first object by assigning a key. All other object should be
created with the place holder as template via method COPY_SELF_WITH_STRUCTURE called on the place holder.
The algorithm repeats recursively for each relation level.
Write access
Creating objects
The creation of objects is separated into the creation of root object instances and instances of dependent objects. In this section we only focus on
the creation of root objects. The creation of dependent objects is explained in section 0.
Root object instances are created within method CREATE_OBJECTS( ). The signature is as follows:
methods: CREATE_OBJECTS
importing
IV_OBJECT_NAME type CRMT_EXT_OBJ_NAME
IV_NUMBER
type INT4
IT_PARAMETERS type CRMT_NAME_VALUE_PAIR_TAB
IV_ROOT_LIST
type ref to IF_GENIL_CONT_ROOT_OBJECTLIST.
The first parameter IV_OBJECT_NAME is the name or type of the root object to be created. This allows a component to implement more than one
aggregational hierarchy. The second parameter IV_NUMBER is the number of instances to be created. The third parameter IT_PARAMETERS is
a table of name value pairs with the given create parameters. With parameters can appear in this table is defined by the create structure given in
the object properties. The fourth parameter is the reference to the empty root list of the data container, were the new instances should be filled in.
As the result of this method the given number of root objects should be created. This means at least object keys (RAW16 GUID) are assigned and
the objects are further known to the component. It is also possible send the attributes for the created object if there are some default values.
Modifying objects
The modify method is probably the most complex method in the interface. It is used for any modification of attributes, and for creation and deletion
of non root objects. The signature is as follows:
methods: MODIFY_OBJECTS
importing
IV_ROOT_LIST
type ref to IF_GENIL_CONT_ROOT_OBJECTLIST
exporting
ET_CHANGED_OBJECTS type CRMT_GENIL_OBJ_INSTANCE_TAB.
The importing parameter IV_ROOT_LIST is the reference to the root object list of the data container. As in the read case the data container
follows some rules, but they are a bit different:
The data container starts always with instances of root objects of the component.
Access objects are treaded like dependent objects.
Each object carries a delta flag to signal its modification mode. The delta flag may state created, modified, or deleted. If it is empty the
object is unchanged and serves only for the structural integrity of the container.
There exists also an implicit export data, which is carried by the data container. We already mentioned that dependent objects are created during
the modify() method. After the creation their newly assigned object key must be set for the container object. That builds automatically a
key-mapping table.
Since the objects in the data container include only the changed attributes and not the full information the attribute properties can be used to
determine which attributes have changed.
Deleting objects
The deletion of objects is separated into the deletion of root object instances and instances of dependent objects. In this section we only focus on
the deletion of root objects. The deletion of dependent objects is explained in section 0.
Root object instances are deleted within method DELETE_OBJECTS( ). The signature is as follows:
methods: DELETE_OBJECTS
changing
CT_OBJECT_LIST type CRMT_GENIL_OBJ_INST_LINE_TAB.
The parameter CT_OBJECT_LIST is a table of object instances, represented by object name and object GUID, combined with a success flag.
The success flag must be set to ABAP_TRUE, if the operation was successful.
A root object instance, referenced in the list, is expected to be fully deleted (including aggregated dependent objects). The deletion on the
database must take place in update task. The commit work is given externally!
Transaction handling
Locking objects
Locking of objects is requested with the method LOCK_OBJECTS( ). The signature is as follows:
methods: LOCK_OBJECTS
changing
CT_OBJECT_LIST type CRMT_GENIL_OBJ_INST_LINE_TAB.
The parameter CT_OBJECT_LIST is a table of object instances, represented by object name and object GUID, combined with a success flag.
The success flag must be set to ABAP_TRUE, if the operation was successful.
Locking is always related to root object instances. If a lock for such an instance is requested the full aggregational hierarchy of the object is
expected to be locked.
Unlocking is then trigger by either the saving or initializing the object.
Saving objects
Saving of objects is triggered with the method SAVE_OBJECTS( ). The signature is as follows:
methods: SAVE_OBJECTS
changing
CT_OBJECT_LIST type CRMT_GENIL_OBJ_INST_LINE_TAB.
The parameter CT_OBJECT_LIST is a table of object instances, represented by object name and object GUID, combined with a success flag.
The success flag must be set to ABAP_TRUE, if the operation was successful.
Saving is always related to root object instances. If saving is requested for an instance the full aggregational hierarchy is expected to be saved.
Database updates have always to be done in update tasks. The commit work is given externally!
Initializing objects
Initialization of objects is requested with the method INIT_OBJECTS( ). The signature is as follows:
methods: INIT_OBJECTS
changing
CT_OBJECT_LIST type CRMT_GENIL_OBJ_INST_LINE_TAB.
The parameter CT_OBJECT_LIST is a table of object instances, represented by object name and object GUID, combined with a success flag.
The success flag must be set to ABAP_TRUE, if the operation was successful.
Filter Relations
A Relation Filter is an optional part of the relation and can be used to restrict the access to data by means of time/date or any other arbitrary filter
criteria. The following figure depticts classes/interface you have to consider when utilizing this feature
Add the name of the filter implementation class to the GenIL model in method IF_GENIL_APPL_MODEL~GET_MODEL() by using the field
FILTER_CLASS of the return table RT_RELATION_DET. Example: see class CL_CRM_GENIL_SAMPLE_COMP.
If you want to support time-period filters, derive your filter class from CL_GENIL_REL_FILTER_TIME_BASE. Provide the supported data/time
format in the constructor. Constants are defined in IF_GENIL_RELATION_FILTER_TIME. Example: see class
CL_CRM_GENIL_SAMPLE_FILTER
If you want to have some arbitrary filter attributes in addition, derive your filter class from CL_GENIL_REL_FILTER_TIME_BASE and provide a
filter structure (DDIC) containing the filter attributes.
The the GET_OBJECT method is executied when data is requested from the GenIL component at runtime. Get a reference to the filter object
from IT_REQUEST_OBJECTS for the requested relations and retrieve data according to the passed filter criteria.
For BOL related information about this topic refer to How_To_BOL_Relation_Filter
Additions
Execution of object methods
Web Service Tool (WST) Enabling
The Web Service Tool enables the customer to easily create web service on top of genIL components. It is not mandatory but recommended to
implement an additional interface and enable the component for being used by the WST. For further information about WST refer to:
Web Service Tool
Web Service Tool UIU Contribution Interfaces - How to Guide
Model definition
A read-only object
A changeable object
Transactional parts
Additions
Example
FAQ
Question: You are using a custom transaction context to handle potential changes on different business objects together. You observe
that for some root objects involved the INIT_OBJECTS method is called from the GenIL framework after you have commited the
transaction. For other object INIT_OBJECTS is not called automatically and the corresponding memory may not released. Why?
Answer:
The object initialization INIT_OBJECTS is called for root objects which have not been touched in the course of the transaction. For the objects
which have been changed it is the responsibility of the GenIL component to do cleanup work in the ON_AFTER_COMMIT event handler of the
GenIL implementation. Since IF_GENIL_APPL_INTLAY~ON_AFTER_COMMIT gets no object list as input, the GenIL component implementation
needs to take care about the objects just saved in the course of the transaction. See internal message 3116886-2009.
Question: I am running a suite7i10 application and get an exception CX_SFW_SWITCH_EXISTENCE. Why?
Answer:
The sample GenIL component references a switch which has not been delivered in suite7i10. By accident the component however was part of the
SHMSET representing the GenIL components loaded into the shared memory for component reasons. In order to overcome the exception and at
the same time accelerate the application start, use the SAP implementation guide to remove the SAMPLE reference in the SHMSET GenIL
component set definition. See customer note 907109-2009.
Question: I'm using method CL_CRM_GENIL_CONTAINER_OBJECT->GET_CHILDREN to access the children of a GenIL container
object. When should I set its parameter IV_AS_COPY to ABAP_TRUE?
Answer:
Set the parameter IV_AS_COPY to ABAP_TRUE in case you do not have to know about new childs added during processing of the GenIL
container object list. In order to get the container list updated whenever a new child is added to the parent container object set the parameter to
ABAP_FALSE. This of course takes away some processing time.
Related Architecture
Generic Interaction Layer
Responsible
Responsible DEV: Uwe Reimitz, Martin Wegmann
Responsible IMS:
Responsible PM: n.a.