Lets conclude our exploration of ABAP OO and using it in SAP workflow. In this final post, Bill will continue his discussion of classes, introduce functional method calls, and give us some great tips we can use as we move forward in our own OO coding. Here is a little bit about Bill….
Bill Craig is the president of ASAP Consulting Inc., located in Centennial, Colorado. Bill has over 10 years of experience with SAP ECC systems and integration with SRM. His areas of expertise include SAP Business Workflow and ABAP development. He made his way into programming as a COBOL programmer, switching to SAP when the company he worked for migrated from mainframe programming to SAP. Prior to programming, Bill ran an upholstery shop in Denver, where he managed the workforce, payroll, sales, scheduling and delivery. You can reach him at firstname.lastname@example.org
ABAP Object Oriented Coding and Workflow BOR Integration
In the first part of this blog regarding the use of ABAP OO with SAP Workflow, I explained how to use an ABAP OO class to start a workflow as well as call one of the methods in the class from a work item. In this final installment I will demonstrate how to instantiate an ABAP OO class from workflow, the use of functional methods, and finally some tips I have learned while developing custom workflows using ABAP OO.
Since BOR is still a common repository for a number of objects it is likely that you have a workflow that is triggered by a traditional BOR event. But for our demonstration purposes you want to use a class to handle many of the functions and rather than add these methods to the BOR. You want to utilize an ABAP OO class.
When the workflow starts you have an instance of the BOR object which is defined by the key fields that were instantiated and passed during the normal event creation. Now you want to instantiate the class which you are going to utilize. Leveraging the class we developed in the previous blogs, create a method that has in input parameter as which is the key to the class, and an export parameter that is a type reference to your class. The method ‘CREATE_INSTANCE’ is defined as static and public.
Create a New Workflow Task
Create a task using the Workflow Development Tools which calls the new method, and make sure to indicate that it is ‘Synchronous object method’.
Next, include this task in a custom workflow. For this demonstration I created a workflow that is started from BOR LFA1 event CREATED. Test the workflow using SWUS passing in the key to LFA1 which is the Vendor Number. View the workflow log and container to see that you now have an instance of the ABAP OO class which will allow you to reference the class methods and attributes.
Within a BOR object you can have different types of attributes, so that once the object is instantiated the value is calculated.
To do the same in a class, you can create an attribute that is populated from a method that is executed from the constructor method. I created a simple attribute ‘VENDOR_NAME’ as a read only attribute. I then created a method named ‘READ_ATTRIBUTES’ which will read the name of the vendor and populate the attribute. I placed the execution of this method into the constructor, and when the class is instantiated the ‘VENDOR_NAME’ is populated and is available to workflow.
An alternative to an attribute would be a functional method. These would be an approximate equivalent to virtual attributes for a BOR object. The added value here is that you can pass in parameters to use during the method, and you can call these methods again and again when you need to rather than only executing the code when the class is instantiated.
I created a method to get the list of user ids assigned to a particular work center. I then created a simple task that passed in the value of the work center and returned the users assigned.
Lastly I wanted to share an issue that I ran into while using ABAP OO with a new custom workflow that I had created. When I first learned workflow I was taught to develop the method first, then a task that calls the method and finally insert the task into the workflow. This would allow the system to automatically generate the container elements required at each step so that I only defined them once at the method level. I still use this practice today, but while developing my first ABAP OO based workflow I had used a method from a class where the return parameter was typed using ‘begin of’ instead of a data dictionary type.
So when I went to create the task to call the new method it automatically created the data element with a definition as below.
This worked in development and tested just fine. The issue was when we transported the workflow and class to the QA environment, the transport failed with a return code of 12. After several attempts to fix it, I finally discovered that the workflow was unable to generate because it could not find the type CLASS=ZCLZZ_WF_DEMO_CLASSTYP which was truncated. In order to fix it I had to create a structure that matched the definition to use as the type and it transported successfully.
Using ABAP OO with my workflows has been a learning experience, which has allowed me to enhance my knowledge of ABAP OO as well as workflow as more SAP developed workflows go down this route. As I stated in the first part of this series, I have been comfortable using BOR for many years, and had to step outside my comfort zone in order to try using ABAP OO. It was not an easy first step, but as with any new skill, the more you do it the easier and better you become.
If you want to read Part 1 of this Blog Series click ABAP OO in your Custom Workflow – Part 1
If you want to read Part 1 of this Blog Series click ABAP OO in your Custom Workflow – Part 2