A business object represents a business entity that has a definite state and various properties. We can carry out various functions on the object. A business object encapsulates the entire functionality of an object.
A business object is given a name in SAP. For instance, a standard material is assigned the name BUS1001006; it has properties such as material number, description, and material type. These properties are represented using attributes of the business object.
The various operations that can be carried out on an object are implemented with methods. For example, if we want to create a material, we can call that business object's Create method. An object also has different states. It exposes its various states by publishing events. For example, the material object has a created event that is published whenever a new material is created.
Transaction code for business objects is SWO1 and menu path is from the Area menu of Workflow, choose Definition Tools, Business Object Builder.
Several business objects are defined in the system and organized in the BOR (Business Object Repository). Objects are implemented as a series of inherited objects, starting with a generic object and ending with a very specific object. The various objects designed for the ALE/EDI process are IDOC related as explained below.
The IDOC object represents a generic IDoc. This object is not used directly in the process, but provides a generic implementation of the attributes and functions associated with an IDoc.
The IDOCAPPL object represents a generic application IDoc used in ALE and EDI. It is inherited from the IDOC object and acts as the main object from which application−specific objects are inherited. Most functions and attributes used in an IDoc are implemented in this object as shown in the figure below. The transaction SW01 display for this object, shows the various components of the IDOCAPPL.
IDOC is derived from the IDOCAPPL object and represents an application−specific object. Although no additional functionality is added after inheriting the IDOCAPPL object, it is the application−specific object that is referenced in the configuration tables.
IDOCPACKET object represents a packet of IDocs.
IDPK represents a packet of specific types of IDocs. For example, IDPKORDERS represents a packet of IDoc orders. The IDPKORDERS object is inherited from IDOCPACKET.
Related Posts
ALE EDI WORK FLOW architechere
Work flow in ale and edi
Work flow management
Working of message control part one and two
A business object is given a name in SAP. For instance, a standard material is assigned the name BUS1001006; it has properties such as material number, description, and material type. These properties are represented using attributes of the business object.
The various operations that can be carried out on an object are implemented with methods. For example, if we want to create a material, we can call that business object's Create method. An object also has different states. It exposes its various states by publishing events. For example, the material object has a created event that is published whenever a new material is created.
Transaction code for business objects is SWO1 and menu path is from the Area menu of Workflow, choose Definition Tools, Business Object Builder.
Several business objects are defined in the system and organized in the BOR (Business Object Repository). Objects are implemented as a series of inherited objects, starting with a generic object and ending with a very specific object. The various objects designed for the ALE/EDI process are IDOC related as explained below.
The IDOC object represents a generic IDoc. This object is not used directly in the process, but provides a generic implementation of the attributes and functions associated with an IDoc.
The IDOCAPPL object represents a generic application IDoc used in ALE and EDI. It is inherited from the IDOC object and acts as the main object from which application−specific objects are inherited. Most functions and attributes used in an IDoc are implemented in this object as shown in the figure below. The transaction SW01 display for this object, shows the various components of the IDOCAPPL.
IDOC is derived from the IDOCAPPL object and represents an application−specific object. Although no additional functionality is added after inheriting the IDOCAPPL object, it is the application−specific object that is referenced in the configuration tables.
IDOCPACKET object represents a packet of IDocs.
IDPK represents a packet of specific types of IDocs. For example, IDPKORDERS represents a packet of IDoc orders. The IDPKORDERS object is inherited from IDOCPACKET.
Related Posts
ALE EDI WORK FLOW architechere
Work flow in ale and edi
Work flow management
Working of message control part one and two
No comments :
Post a Comment