Skip to Content
Author's profile photo David Halitsky

How SAP Gets in Its Own Way on the Road to Enterprise SOA

Those of you who run the QM module and are familiar with workflow probably know that there is a Business Object modelled on the QALS table – BUS2045. I was recently able to customize a delegation of this object and very quickly create a simple custom workflow triggered by the STAT35 column of QALS being set to ‘X’ by transaction QA11 when a usage decision of ‘A’ (accept) was made on an inspection lot. (There’s a little more to this story involving the STAT19 column of QALS, but that’s another story for another time, and it’s really not an issue if you’re willing to turn on the “doc history required” flag for all your matnr’s.) But I didn’t have the same luck with the next customer requirement – to automate usage decision-making without using the SAP program RQEVAI30 running like a UNIX daemon in background. The problem here is that this program uses some nasty nasty logic against the JEST table to see if an inspection lot is “ready” for an automated usage decision. And unfortunately, this logic is “work-flow” proof because the JEST table allows no change history to be written from it, and therefore no events to be triggered from it. On the other hand, there are two columns I could use in the QALS table to detect when there are no more open tasks against a lot, but the data elements for these columns don’t support change history. Otherwise, I could create a custom event when these columns go to 0, do a start condition to check a couple of other things, and then trigger the usage decision method of BUS2045. So, I’m going to suggest to the customer that we do a minor modification to the data elements QOFFENLZMK and QOFFELZMK underlying QALS-OFFENNLZMK and QALS-OFFEN_LZMK so that change history on them is written. Then, I can generate a change object against these and “PROBABLY” find a custom exit in XQEE where I can stick the change object document write program to make sure that CDPOS winds up with the correct trace on these two columns. But the point of this blog is: as long as SAP makes RQEVAI30 available to its customers as a 1987 solution masquerading as a 2007 solution, what customers will pay for what my current customer is paying me to try to do here? (I’m lucky that this customer is forward-thinking enough NOT to want to adopt 1987 solutions for 2007 problems.) And as long as most customers won’t pay to get out of the last century, they sure as heck ain’t gonna get into the workflow way of thinking that’s a natural prerequisite for development of a true Enterprise SOA mindset.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Reading your blog about problems with some program full of annoying details, I wonder what you want to achieve with it. I think the SDN-community knows very well that SAP cannot be seen as a full blown E-SOA platform yet, simply because a lot of stuff has been built before the word 'SOA' was even invented. So if this blog is only intended to write something down because you're pissed off maybe you should use antother medium for that -:).

      Greetings Theo

      Author's profile photo Former Member
      Former Member
      I think the point is that as the world transitions to an SOA world, with the goal being extensible and configurable business process, providing the necessary "hooks" to enable this must be *designed in*, not taped/glued/stapled on after the fact.  And, since many of the ESA services have their foundations (read: code) in existing BAPIs and RFCs, this is sure to be a challenge.

      Additionally, the "classic" SOA metaphor involving HTTP, SOAP, etc...does not cleanly lend itself to things like "callbacks", "handlers", "delegates", and other structures.  There are a zillion ways these things have been implemented in real-world applications, but not uniformly, from what I've seen.

      In any case, at the risk of trying to read David's thoughts, I feel that he is simply sounding a warning bell that we should all listen to.

      - Rick

      Author's profile photo David Halitsky
      David Halitsky
      I can envision a day when any appropriate "hook" can be selected via point and click without fear of error or oversight, but that day is many person-hours away. 

      For example, even the update I posted to this blog regarding the provided event in QE51N is still not the correct solution, because the event in the standard business object BUS2045 simply calls QA11 as a "work-item" for someone's workplace - it doesn't allow a background usage decision "untouched" by human hands.

      Furthermore, the correct solution - a background function call out of the exit associate with enhancement QEEM006 in the ZQEE function group, requires reference to one internal table and two transparent tables to determine if an inspection lot is, in face, ready for an auto usage decision.

      So the total of "investigation/experiment" hours on this matter is now adding up to a couple of days, and that kind of investment may well prove to be an intolerable drag on efforts toward SOA solutions.

      I already know that my concerns here are shared by several other SDN'ers who are far more experienced than I.  But it's good to see this concerns recognized by an SAP "insider".


      Author's profile photo Former Member
      Former Member
      Author's profile photo David Halitsky
      David Halitsky
      ... then I am very proud of the two responses this post has garnered.

      One response is from one of the reigning "kings of bling" here at SDN

      And the other is from someone whose professional title (Cap Gemini Enterprise SOA Solution Architect) strongly suggests a master at generating what I've elsewhere called "high-margin/low-risk" deliverables.

      OK - now that we've got the introductions and pleasantries out of the way, let me try to answer Theo's question.

      My target group is the folks at SAP who have to decide how to gear the back-end up for Enterprise SOA and whether this process will be an evolutionary one or a revolutionary one.

      There are more than a few of us at SDN who think that the process should be evolutionary, and might well start with a demonstration that SAP is capable of UNIFORMLY gearing-up its back-end for workflow.

      If SAP can't UNIFORMLY gear its back-end up for workflow, why should anyone believe that it can ever sufficiently gear-up for Enterprise SOA, which places even more stringent demands on back-end infrastructure?

      If my point is still unclear, just ask yourself how long workflow's been around and how many clients are using how much of it ?

      Author's profile photo Stephen Johannes
      Stephen Johannes

      You example is just one of many issues that we are going to technically face going down the whole enterprise SOA route with our existing SAP investments.

      For those doubt the importance of issues like this, take a look at this thread:
      If master data is backbone of ESA then why BDC?

      The best analogy is one I used to use for B2B sales e-commerce projects.  All your dirty laundry gets exposed when you do an e-commerce implementation.  Likewise all our dirty laundry will be exposed when we do an enterprise SOA implementation. Basically your shortcuts will be revealed and become your pain points.  All your sticky note processes and wetware knowledge bases, will be revealed.

      Take care,

      Author's profile photo David Halitsky
      David Halitsky
      I remember your Coffee Corner thread very well - it provided one of the empirical foundations for my being able to say what I said in response to Theo here.

      The other problem is, of course, the fact that the "high-margin/low-risk deliverables" crowd MUST behave as if they truly believe that we are advanced beyond the era of mere technical issues - that Bill and Larry and Shai actually succeeded in turning IT into some kind of alchemy that automatically implements functional designs with nary a glitch or a hitch.

      Oh well - it took the brightest minds in the West hundreds of years to realize that you need a super-collider if you really want to turn lead into gold.

      So why should it take less time for CIO's to realize that the alchemy promised by "high-margin/low risk deliverables" doesn't work either?


      Author's profile photo David Halitsky
      David Halitsky
      In fairness to QM developers, it should be noted that transaction QE51N does raise an event which can be trapped and used to trigger a workflow which uses a standard method of BUS2045 to make a usage decision automatically.

      BUT, for some strange reason, QE51N raises exactly the same event as transaction QA02, and transaction QA02 must be invoked prior to QE51N in the normal SAP QM process in order to assign a plan to a lot.

      So, the workflow triggered by the raising of the event needs a check function module to see if the inspection plan is really ready for an automatic usage decision.

      Now coding a check function module is not the "end-of-the-world", but suppose that someone saw the QE51N event and didn't bother to do enough up-front analysis vial SWEL (display event trace) to realize that QA02 also raises the same event.

      The outcome of this failure of analysis would not be pretty.

      So the moral of this story is the same as it was originally: standard SAP infrastructure will have to be gone over with a fine-tooth comb before it is ever ready to support any meaningful Enterprise SOA apps.

      In this case, for example, a different event should be raised by QE51N - one that unambigously announces:

      "Hello, world! This plan has passed and is ready for an automatic usage decision of 'A'.