Modeling Business Objects

You model business objects so that the resulting attributes and data types can then generate other tables, define table relations, and implement basic methods for reading, writing, updating, deleting, and querying data.

You have opened the Service Composer perspective in SAP NetWeaver Developer Studio.

1. Create a business object node.

   For more information, see Creating Business Objects .

2. Model business object attributes.

   You can create new attributes, subattributes, or relations to other services. You can also delete attributes or attribute properties after creating them.

   For more information, see Modeling Business Object Attributes .

3. Model business objects operations.

   For more information, see Modeling Business Object Operations .

4. Define access rights.

   For more information, see Protecting Access to Business Object Operations .

5. Define persistency type.

   For more information, see Defining Business Object Persistency .

6. Define associations.

   For more information, see Defining Business Object Associations .

7. Expose the business object as an external service.

   For more information, see Exposing Application Services or Business Objects as Web Service .

8. (Optional) Customize the BO implementation.

   For more information, see Customizing CAF Model with Own Implementation .

9. (Optional) Set up locking and unlocking of business objects during data load.

   For more information, see Locking Business Objects .

   Caution

   If you rename a business object and its appropriate table name, the old dictionary metadata still will be available. The reason for never deleting the dictionary table files from the file system is that if one table has already been deployed, this table descriptor is always needed to be able to undeploy it.

   As long as this rename affects only a single DC, you should not experience any problems. However, if you use a business object or a table with the same name in another DC, the following situation may occur: after deploying the second DC (the one that contains the renamed artifacts), the old table names are deleted, although they are still used in the first DC.

   That is why you have to manually delete the old metadata physically from the file system (dtdbtable files in the /src directory of the second DC's dictionary project).