2.business object repository
5 likes2,342 views
The document discusses business object repositories and business objects in SAP workflows. It defines business object repositories as collections of business objects that integrate business application data and functions into workflows. Business objects provide an object-oriented view of business applications, organizing data and functions into reusable components. Key topics covered include business object types, attributes, methods, events, relationships between objects, and tools for working with business objects.
2.business object repository
- 2. Business Object Repository Business object repository is a collection of business objects. Business objects integrate the data and functions of business applications into your workflows. They enable the communication with business applications with all the flexibility and robustness required for a production environment. Business objects are also the main interface between SAP workflow and business applications in SAP components. Business objects helps to minimize development and maximize return on investment you have already made in implementing your SAP component. Business objects give the SAP workflow access to the data and functions in business applications. A directory of all object types defined in the SAP System is managed in the business object repository. These object types are each assigned to a business application component. In addition to the business object types, the business object repository also contains structural object types, such as company code, plant, or sales organization, and technical object types, such as text, note, work item, or archived document. Customers can define their own object types. Object types and their elements can be found quickly by accessing this business object repository with the appropriate search functions (either via the component hierarchy or with a generic search using parts of a name).
- 3. Business Objects Business data can be used : In control steps (including conditions, loops, container operations) In bindings (including event to workflow, workflow to task, task to method, workflow to rule) In texts (including work items texts and user instructions) In start conditions used to determine which workflow will be started and whether a workflow will be started. Business functions can be used : In methods, within tasks, within workflows In agent determination rules and XML rules. In event linkages with start conditions, check function modules or receiver type function modules. In secondary before and after methods within workflow step definition.
- 4. Business Objects Business objects provide you with an object oriented view of business applications. They organize the business data and functions into the reusable components that can be accessed throughout the workflow. From a workflow perspective, the main advantage of object-orientation are : Reusability : Each piece of business data and business function defined is potentially available to all workflows. Business data is available as an attribute of an object and Business function is available as a method of an object. Encapsulation : Each piece of business data and business function is defined once and only once for the most relevant business object. Inheritance : SAP provides many business objects with data and functions, instead of starting from the scratch, you can inherit the SAP- provided business objects to your own business objects. You can even replace provided data and functions with your own. Polymorphism : Business objects allow generic programming.
- 5. Relationships Between Object Types or Business Objects A business object type can have various relationships to other business object types. Relationship between attributes are extremely useful throughout workflow. Relationships are as follows : 1 . Inheritance : (inherits from) Relationship between object types allowing common attributes and methods to be passed automatically from supertypes to subtypes. The object type which passes on attributes and methods is the supertype. The subtype takes on ("inherits") the attributes and methods from the supertype. The supertype program coding connected with the attributes and methods is referenced. Inherited attributes and methods can be redefined for the subtype. The interface, however, may only be enhanced. If the attributes and methods of the supertype are known, it is only necessary to describe the differences (changes and enhancements) in the relevant subtype. All other attributes and methods defined once are used again which reduces the implementation work involved. The error probability when changes are made later also decreases. In inheritance, the subtype usually has the same key fields as its supertype, but enhanced functionality.
- 6. Composition : "Is part of" relationship between object types. The object type order item "is part of" the object type order . The object type order is then the aggregate type of the object type order item . In composition, the ‘is part’ object type usually has an extended key when compared to the aggregate type (for example, order key + item) and a completely different functionality . Composition relationships are implemented by creating an attribute that links one object to another. Interface : Relationship expressing which object types support an interface. To maintain this relationship, the relevant interfaces must be entered as components of the object type. Association : Relationship between object types resulting from an object type being referenced as an object attribute of another object type. The object type customer is referenced in the attribute ordering party of the object type sales order . Relationships Between Object Types or Business Objects
- 7. Business Object Tools There are two main tools that you can use to work with business objects: 1. Business Object Builder : Transaction SWO1 or Definition Tools ->Business object builder. Use the Business Object Builder to display, test, create, generate, change, delete, delegate, and change the status of business objects. You can see all the relationships between object types using Utilities -> Relationships on the initial screen. To access a business object type in the Business Object Builder use its technical ID 2. Business Object Repository Browser : Transaction SWO1 or Definition Tools ->Business object Repository. Business object Repository browser presents a hierarchical view of all the business objects available, by SAP application module. Each object type is assigned to an SAP application module indirectly via its package. You can inspect the definition of existing object types, but you cannot create new object types here.
- 8. Business Objects : Some Basic Terminology While using business objects you may be referring some of the following terms: 1. Object type : It is a design and implementation of the access to data and functions i.e. the object types contains the program that reads or calculates data and calls business functions. 2. Object Instance : It is a single runtime copy of its object type that holds the data or accesses the functions relevant to that particular instance of the object. 3. Object reference : It holds the technical ID of object type, the object key, and other technical information needed by the system to access an object instance. Each object of business object type has the following components. Key Field. Attributes. Methods. Events.
- 9. Key Field Fields for unique identification of an object. The key defines each object instance uniquely. For e.g. for the Customer object type the key is customer ID. The definition of the key fields of an object type determines the structure of the identifying key, via which the system can access a specific object, that is, an instance of the object type. The key fields of an object type are usually also the key fields in the table containing the header data for the object type. Only character-based data types are allowed as key fields. The total length allowed for all key fields is 70 characters. Each key field refers to a field in the ABAP Dictionary. Key fields are simply declared within the object and are filled when the object is instantiated. Each key field must have a reference to a ABAP Dictionary table/field. This is used to define the data type and length of a key field.
- 10. Creating Key Fields Steps for creating the key field : Key field is provided by calling workflow, task, method, attribute or event whenever the object is used. The object instance instantiated from the object type and key, give you access to all the attributes and methods of that object. Example: We will add the Material ID as a key field of some object called ZWIDGET1. If you are not using BUS1001 object type, we can create the same fields with the same data type references as your example object type. Bring the ZWIDGET1in change mode to add the key field by choosing the component title “Key” and choosing ‘create’. Base the key field on the dictionary table MARA field MATNR. Once the key field has been created, go back to the object type program and see that the object declaration has changed. Regenerate and test your new changed object. Attempt to add a new key field to ZWIDGET2. Key will not be added since ZWIDGET2 is a subtype.
- 11. Attributes Attributes provide access to business data. This may be data extracted from the database or calculated values. Attributes may reference a single value or multiple values. Attributes can in themselves be references to other business objects, setting up relationships between objects. Attributes can be used to formulate conditions in the workflow definition. The system reads or establishes the attribute values at runtime and controls the workflow with them. A object attribute can return data as follows: The value of a field of the ABAP Dictionary (database field attribute) An object reference to an object defined in the Business Object Repository . The attributes of an object are defined and implemented as components of an object type in the Business Object Repository. Attributes are passed on from the supertype to its subtypes.
- 12. Creating Attribute Bring the ZWIDGET1 in change mode to add a new attribute by choosing the component title “Attributes” and choosing ‘Create’. Click on yes to the question “Create with ABAP Dictionary field proposals?”. Base your new component on dictionary table MARA field MTART (Material type). Accept system’s proposal for names and descriptions of an attribute. Notice what checkboxes and values have been set for you in the attribute details screen. You will see that the attribute ID, name, description, database flag, and data-type reference have all been set for you. Notice that the attribute is only in modeled status. Save your object and regenerate it. Try testing your object. Can you use the new attribute in modeled status? No. Go back to your object, choose your new attribute and choose Program. The system will ask you if you want it create an implementation for your attribute. Click on Yes. Do not change the code generated at this stage, just inspect it. Note that status of your attribute is automatically changed to implemented. Regenerate your object and test it again with the valid material number. This attribute will show the material type for material chosen.
- 13. Methods Method provide access to business functions. Method is also known as operation that can be performed on an object. The methods of an object are defined and implemented as components of an object type in the Business Object Repository. Methods and their interfaces are passed on from the supertype to the subtypes. A method generally refers to ABAP/4 functionality which is already available (function module, transaction, dialog module, ...) and is called via an interface determined mainly by the method name and method parameters. The actual implementation of the method therefore remains abstract. It is not visible externally and does not need to be known to the calling program of the method. If you want to use a function in a workflow, it must be first defined as a method of an object. A method is usually a single activity that can be performed on an object instance. A method may involve a combination of business functions or even call other methods within its program code.
- 14. Synchronous and Asynchronous Methods Methods can be subdivided as follows depending on their response characteristics: Synchronous methods Synchronous object methods assume process control for the duration of their execution and report back to the calling program once they have been executed. Synchronous methods can accept import parameters and a result, export parameters, and exceptions. Asynchronous methods Asynchronous methods do not report back to the calling program directly after their execution. The response is made via events which are used to report the processing results of the methods. Asynchronous methods can only accept import parameters; they cannot return any results to the workflow directly. Results can be returned indirectly via terminating events. Synchronous and asynchronous methods can be distinguished according to the way in which they are used in single-step tasks: A single-step task which refers to an asynchronous method must be completed by an event.
- 15. Method Parameters and Result Method Parameters Parameters are used to exchange information between the calling program of a method and the method. Parameters of a method are values which are either passed to the method at runtime (import parameters) or are returned from the method (export parameters). When the parameters are defined, the interface of the method call is also defined. A method need not necessarily have parameters; many methods can be used without parameters. Method Result The result of a method is different to the export parameters. Possible values for the result can be fixed or contained in a check table. They are therefore known in a workflow definition and can be taken into account during process modeling. The various follow-up steps can be modeled in a workflow definition according to the results. A method can only ever have one result, although there is no limit to the number of export parameters. A method need not necessarily have a result.
- 16. Events Events transmit the status change of an object (e.g. Created, Changed). Events should always be seen in connection with the object they are "reporting" on. The events belonging to an object are therefore specified in the object type definition. Events are published without the application, the event creator, knowing whether a receiver is interested in this event and whether it will respond. Potential receivers of an event are listed in the event receiver linkage table, where receivers can make and remove their entries as required. This allows the events created to be responded to flexibly. Events are used in the SAP Business Workflow environment. to start tasks (multistep tasks and single-step tasks). The events are therefore defined as the triggering events of the respective tasks. to complete single-step tasks which refer to an asynchronous object method. The events are therefore defined as the terminating events of the respective single-step tasks. Events are linked to runtime-dependent data (event parameters) which is available to the event receiver and can be used for event-driven control and communication mechanisms.
- 17. Creating Events Steps for creating events: Bring the ZWIDGET1 in change mode to add a new event by choosing the component title “Events” and choosing ‘Create’. Give your event a name. Regenerate your object and test it.
- 18. THANK YOU