Skip to Content

The subject I would like to share with you here might already be discussed somewhere else, but as I didn’t find  any doc on this particular integration, I decided to write this blog to share what I use to do when designing a Business Workflow in SAP ERP. After several integrations to different Customers, I had quite good feedbacks about it.

The typical scenario


Let’s say you must implement some kind of frontend capturing some data from end-users. Data must transit between different actors who must carry out some actions on them (approval, changes,…). Some emails must be triggered as well. Typical I said. Seems a workflow could be useful here to design the process.

Layers

Ok, for the process, we plan to use a workflow (ERP based one). The frontend is going to use a MVC pattern, model would be implemented using an ABAP class (Web Dynpro/BSP/UI5+Gateway/…). Ultimately, data for our request will be defined as class attributes.

Then comes the persistence part. Several options here: simpliest could be to store persistently our attributes in the container of the workflow. But what about the Segregation of Concerns? That also means we would lose our OO model and even the OO world. Development cycle is tougher as it will require more interactions between the workflow expert and the frontend developer. As a second option: you might know that SAP provides an Object-Relational Mapping tool called Object Services (that includes the Persistent Service) and allows you to make your objects “persistents”. For who doesn’t know yet what is it: http://en.wikipedia.org/wiki/Object-relational_mapping. I won’t explain in details all the advantages you can have using such a framework, but if you never played with it, I highly recommend it. You can find collaborative doc on how to implement that in SAP here: http://scn.sap.com/docs/DOC-27055.

Great! Let’s say we opted for option two, so our model is an ABAP persistent class. Another good news is that Business Workflow can be implemented using a class also! So no needs to pass a Business Object to our workflow or copy the data in the container. Simply implements the interface IF_WORKFLOW.

Visibility

Instanciation of a persistent class is protected . A dedicated “Agent” singleton class is provided to manage your instance(s). That also means, if you decide to implement the IF_WORKFLOW interface in the persistent class itself that the workflow engine won’t be able to instanciate the class.

Even “technically” you can make that model working, you’re going to face problems when using standard transactions to manage your workflow instance. I would also add to keep these two things separated, from a design perspective.

A (cleverer) way

The goal here is to get a reference to our persistent object (the model) in the container of workflow (so the data are not stored in the container or even copied locally but consumed in our workflow nodes directly).

The workflow uses a instance ID when getting an instance of the workflow class (LPOR-INSTID, 32 characters long). That’s one part of the LPOR key used by the workflow (two other ones can be set statically).

On the other side, our model has a unique key as well. Let’s assume here to keep it simple that we used a GUID as unique key for our persistent object. Means a RAW16 data type. Means a 32 characters long when represented.

The trick here is to get back the GUID from our persistent object and pass it as the instance ID of our workflow class, typically when creating the workflow instance. The reference of our persistent object (declared locally in the workflow container) will be set every time you access the workflow calling the “get_persistent_by_oid” method that the Agent class provides in the “find_by_lpor” method that you must implement (main one of the IF_WORKFLOW interface). So “find_by_lpor” returns an instance of the workflow class containing a reference to your model. I pasted a short core example below:

Must have attributes in your workflow class:

    

Short exemple of “find_by_lpor” method, commented:

    

Then when retrieving data in workitems, you can invoke the getter methods of the persistent object  using this pers_ref reference! Nothing else to do… Done.

Basically the data model is decoupled from the process flow.

Hope

This is my first blog on SAP SCN, I hope you found it interesting, or even better useful! 🙂 Any thoughts, other ideas or comments are welcome.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Paul Hardy

    This is a very interesting topic, the following is not me agreeing or disagreeing with you, just some general thoughts on the topic.

    I do a lot of workflow, and often I have the situation where you store the user input in Z tables in the database.

    At first glance, a persistent object sounds just the thing. I ran out and got the “object services in ABAP” book (SAP Press) and read it end to end. And then read most of it again because I could not believe what I was reading.

    Unless things have got a lot better since that book was written, the whole concept seemed to be riddled with limitations.

    It MUST have got better, at that point (2010) you had to declare you structures with the names in alphabetical order( for example) for them to work with this framework, something unheard of in normal ABAP programming – that must have been fixed by now.

    Also the whole concept of “getter” methods should be alien to ABAP Objects, Horst Keller keeps saying that instead you are supposed to have public attributes that are read only to avoid the need for this.

    The authors of that book included a section on workarounds for the limitations that existed at that point, which was good.

    I would be fascinated to know if many people use persistent objects and to hear about any concrete benefits achieved.

    You would think if they were so great then SAP would have released standard persitent objects for deliveries and such forth.

    In fact I believe there is yet another persistent object framework that has been created – BOBF – Business Objects Persistent Framework – see blogs by James Wood – which uses a totally different mechanism – just as complicated – to manage such things. There are standard SAP classe here though.

    All of these are supposed to be simpler than just creating a ZCL_DELIVERY class that reads from LIKP & LIPS but I wonder. I really do.

    I totally agree with your points about the seperation of concerns, I am just putting the cat among the pigeons about the various ways in SAP to achieve such a thing, and the merits or lack of in each case.

    And well done for blogging on SCN, the more blogs like this the better.

    Cheersy Cheers

    Paul

    (0) 
    1. Olivier Gaspard Post author

      Hi Paul,

      Thanks for your thoughts, that’s the goal indeed of such blogs.

      I see your point, especially your concerns about the maturity of the ABAP OS framework. Using it regularly, I must say ABAP OS does most of what I expect of an ORM tool… But to agree with your concerns, I could write another blog on open questions I’ve got also 🙂 As an example, I regret it doesn’t generate the database schema itself, as you can find with certain non-SAP ORM tools.

      Personally I don’t see it as “one option” between others SAP provides, but (the right) tool to use if you want to deal with DB tables “natively” in OOP.

      Ok, I won’t try here to convince someone to use the OS or not 😉 but I think it was important to highlight the integration with BWF for those who like me are keen to develop [only] in a OO manner.

      Actually SAP already uses the OS framework for certain scenarios in their Business Packages such as ESS/MSS (Web enabled).

      Thanks Paul for your comments!

      Oli

      (0) 

Leave a Reply