http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/webcontent/uuid/925b02f9-0b01-0010-bbbf-c...http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/webcontent/uuid/50fa01f9-0b01-0010-f1bf-c... http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/webcontent/uuid/40d903f9-0b01-0010-4fab-c... Object Oriented programming is fully supported in ABAP. In fact it has been there for quite sometime. So, what does it really mean for Functional and Business Process Experts? This BLOG will briefly describe what ABAP-OO is, highlighting the value added of this technology for the Business. Development Goals This may sound redundant, but the main development goals are aligned with one of the main IT goals: Lower TCO. Am I being simplistic here? I dont't think so. Reducing development cost is a much broader goal than one may think. Development quality is very important. So, breaking down the development goals into more tangible points mean: 1 - Implement code reusability; Having business logic replicated in many programs lead to higher maintenance and support costs. Often these logics are not in-sync after a while and different programs start to give different results. 2 - Achieve higher code Reliability; The more a solution is reliable, the less it will cost to support it. Simple? Yeah, yet often we don't see it developed that way. Reliability is achieved with Reusability and with the fact that the Object oriented model implies a cleaner design. Also the communication between development and functional team is done better. 3 - Make code maintenance easier; Often solutions are created and changed in no time. Aften by many developers. This means that not only as a result of the original design but also as a consequence code modifications, the programs used are often very clear of what it is intended to perform. Object oriented programming models can achieve a much easier design and as a consequence simpler maintenance. 4 - Use up-to-date technology; As an example, most of the Enjoy Purchase order transactions ME21n, ME22n, etc. are created havily using Abap Objects. If you want to implement BAdIs to change these screens you will need to have experience on Abap Objects. If you have this knowledge within your development team, you won't have to rely on external consultants (costly) Real World Scenario - Example For now, lets just give an example of a development request: "We would like to automatically update a custom field in the delivery with a value based on a Business logic whenever it is saved". Fairly straight forward uh? Now things start to get more complicated: The functional spec is written more or less like this... "Upon save, check the value to be passed to the custom field using the following logic: Delivery has a billing document = 7 Delivery Goods Issued = 6 Delivery Picked = 5 Delivery Printed Pick List = 4 Delivery planned for Shipment = 3 Delivery Validated by Warehouse = 2 Delivery Created = 1" Questions will arise: 1 - How do I determine all those statuses?. 2 - How do you want to update the delivery? (batch inut or direct input)? Will I have lock problems? My example helps highlight 2 important things: 1 - Important decisions like how to get different delivery statuses or how to update it, should be done once, coded well and reused. 2 - With the possibility of reusability, the functional team should not be always involved with some technicalities like this. How can Object Oriented programming help me in this case? Object Oriented programming can be used to create an extra programing layer that will mainly create a bridge between functional requirements its technical implementations. Think about BAPIs (Business Aplication Programming Interface). You probably have already worked with them. Why are them so appealing? You can find on BOR (Business Object Repository) sevearal Business Objects that have names like SALES_ORDER and methods like CHANGE. This is why they are often used. Now, back to our example. What can be done here is an initiative to start creating global ABAP classes to represent your busines objects. (Global simply means that they can be reused throughout your system). Imagine this... The requirement is still the same. The developer than goes in the global class repository and look for custom class ZCL_DELIVERY. He finds it. More importantly, he finds that there is a methods already created for it: Get_custom_status. Cool. Further search reveals that there is also a class ZCL_SALES_ORDER with method Update VBAK. No further questions needed. The code would look a bit lik this: create object o_delivery exporting delivery = likp-vbeln o_delivery->get_get_custom_status( ). o_delivery->likp-zzcustom_status = o_delivery->custom_status. o_delivefy->UPDATE_LIKP( ). As you can see, we guarantee 2 things here: 1 - The business logic is reused; We didn't have to bother on reading custom status. 2 - Program is structured in a way that directly relates to the original business requirement. This is a very important quality of the program. Maintenance is easier since it clearly defines what it is supposed to do (easier maintenance). Also, Functional team members and BPX Professionals can read the code and understand its logic with little effort. In my example the developer found the required class and method in the global class repository. The reason was to show the advantage of code reusage. Now, if the class/method is not found (very probable) then the focus is turned to creating it in the global repository. Following the approach, do it once, well and reuse it, we should not spend time and money reinventing the wheel. Conclusion Oriented Object Programing is a lot more than just a technical tool for developers. It is also a methodology that improve the overall quality of custom developments. The problem is that today most of the times, the decision of using it or not is made exclusively by the developer since the functional team has very little understanding or exposure to it. That is why I decided to write this Blog. I think we all have to gain from it. I will be posting very soon another BLOG called Crash course on Oject Oriented ABAP for Functionals and BPX. There I will quickly explain what methods, attributes and instances are. Stay tuned.
