A little background history for those who know BOR VERY HELPFUL TIP! If you are an ABAP OO programmer and never did any code in the Business Object Repository, skip this section... you don't need to know about it, and you probably don't want to know either. Once upon a time, in the land of BOR (Business Object Repository), there were 3 types of attributes: - Database attributes
- Virtual attributes
- Status attributes
Database attributes were always the easiest of attributes - just say what table and field you want to read and the BOR would generate some code to read all the data from a record of the table. You just had to fill in the blanks. Then you could add other database attributes referring to the same table and they would all use the same pre-generated code. Easy for workflow devlopers, but not always the most efficient way to read code, as you may only be using one or two fields but you still read the entire table row. Virtual attributes were the most useful type of attribute as you could derive anything here including complex values, structures, tables, and instances of other objects. Status attributes were a neat trick for business objects that used SAP status management, but most programmers didn't even know they existed. By using a special interface, and filling in the code behind a few predefined virtual attributes, you could then generate a yes/no flag to indicate if a particular status of that object was active. In ABAP OO we no longer make the distinctions between these different types of attributes. So what do you lose? No more pre-generated code. And what do you gain? Flexibility and control over how your attributes are coded so that you can make the code as performance-efficient as possible. Tip! Wanting to find whether a status attribute is set or not? Just call function module STATUS_OBJECT_READ with the status object number. All the statuses set for that object will be returned. Read entire blog here https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/4203
Related Items:
|
