Skip to Content

Why ABAPers should take BIT600/01/10 even if they’re gonna work in VC/CAF eventually

A little while ago, there was some back-and-forth in the forums about why workflow is in a BPM/Workflow forum rather than its own forum here at SDN. From what Mairlyn and Alan and others said in that discussion, I came to understand the functional reasons for this placement of workflow in the forums. But having just completed BIT601 and looking foward to 610, I can also understand the technical reasons for this placement. OK – if you were at Tech Ed 2006 in Las Vegas or elsewhere, you probably heard a great presentation about the MVC (Model-View-Controller) construct in WDA/WDJ and how it relates to the standard Javaesque view of the world. (I think this presentation was by Karl Kessler – if not, I apologize to whoever’s it actually was.) In any event, I was so inspired by this talk that I came back to Nashville determined to at least learn how MVC is implemented in WDA in detail. And as you all are aware, PAINFULLY aware, I managed to learn quite a bit about the MVC constuct in WDA by trying to do an “event-driven self-tutorial” on modifying the WDA component WDY_TEST_UI_ELEMENTS and blogging about this effort here. Well, sometime in the middle of BIT601 this week, Dereck (Purnell) happened to point us to the SWC* function modules that support operations on various types of workflow containers … gets, sets, etc. And once I saw those, it immediately got me thinking about the bindings that are done in workflow among containers and workflows, tasks, steps, rules, etc. And all of a sudden – the light-bulb went off in my head. (You have to realize that I’m a bear-of-very-little-brain like Winnie-the-Pooh, and not a wunderkind techie like some here.) Yes folks – you heard it here first (ha-ha!!) – containers in workflows are “kissing cousins” of controllers in the WDA/WDJ MVC construct, workflows are “kissing cousins” of models, and step-types are “kissing cousins” of UI Elements. Now for some folks here – a lot of folks probably – this is old old news. But for me it was like a revelation, particularly because the MVC construct deals with events tied to an essentially spatial frame (the screen) whereas workflows deal with events tied to an essentially temporal frame. And the similarity of temporal workflow to spatial MVC appealed to me because if our current view of the universe is correct so far as it goes, then there should be all kinds of logical operations that do just as well in space as in time. But anyway, I really think that if an ABAPer has never done workflow nor WDA/WDJ, it would be very worth his or her time to take BIT600/01/10 for no other reason than as a technical “intro” to WDA/WDJ, VC/CAF, and NWDS. It’s always best to go from what you know to what you don’t yet know, and workflow provides exactly the right path from ABAP OO to WDA/WDJ, NWDS, and VC/CAF.

You must be Logged on to comment or reply to a post.
  • A few months ago I was playing around with WDJ framework and got to understand how to design an application under the MVC pattern (thank you SDN for that!). Later on, one of my workmates was teaching me some stuff about Workflow and when I understood the idea behind containers, I realized of the same idea you express in your weblog.


    • From a “functional” or “semantic” perspective, most folks would probably say that a guided procedure is the equivalent of a workflow.

      But from a purely “technical” or “syntactic” perspective, I’m sure that the real experts (the SAP internal developers) would agree that:

      container ~ controller
      workflow  ~ model
      steps     ~ UI elements

      Thanks for taking the time to respond.  Good luck in your explorations.


  • An interesting analogy, but I can’t say I agree. If I had to try to match the somewhat tenuous analogy I would rather suggest:

    container – model
    workflow  – controller
    tasks     – view

    Why? Quite straightforward really: The container and associated business objects contain (pun not intended) the data – a model’s job.
    Tasks form the user experience – view could apply here.
    Workflow orchestrates the lot – certainly closer to being a controller than a model.


    • It’s a very interesting question because as I pointed out in my response to E in this thread, folks may reach different conclusions if they’re thinking “semantically” vs syntactically.

      After learning how the Workflow engine needs bindings between steps/tasks and containers, I immediately drew the “syntactic” parallel to UI elements binding with controllers.

      And I think this limited analogy is correct from a “syntactic” point of view, even if your analogy is equally or more persuasive from a “semantic” point of view.

      Not to prolong this discussion unnecessarily, but if you don’t think these two instances of binding are precisely parallel “syntactically”, I’m curious to know why you don’t.


    • … so far as I know.  SAP won’t even sell the manuals to folks who don’t necessarily feel they need to attend the courses in person.

      Any way, good luck with your endeavors.  If you purchase the Rickayzen/Dart/Brennecke/Schneider book, you can learn a lot without the course manuals or hands-on class training.

  • I agree.

    At the time it came out workflow from SAP was regarded as rocket-science because it introduced such abstract concepts.

    But, the tool and above all the workflows created with the tool have withstood the test of both time and change, thanks to this model-driven foundation.

    Glad you spotted it,

    • Hi Alan –

      Glad you concur concerning the basic parallel I thought I had seen – makes me feel less stupid.

      With respect to the “abstraction” of work-flow, I am a little surprised.  To me, everything I learned in 600/601 was kind of “intuitive” – like – “yes – how else would anyone want to do it?”  And I suspect when I take 610 in a couple of weeks, I will react the same way.

      On the other hand, in the JAVA/OOP world, there sometimes seems to be a tendency to pick fancy and obscure terminology to make sure everybody realizes what an important “paradigm-shift” JAVA/OOP represents, and how brilliant the new paradigm really is – how different it is from the stuff that those poor ignorant procedural programmers do.  See, for example, my thread in Coffee Corner on the OOP term “interface”.

      BTW, my current customer has a workflow with literally dozens of subworkflows and hundreds of steps/tasks, and I’m about to start learning it for support purposes – so by the time I’m done, I’m sure I will have encountered everything in your book and everything taught in 600/601/610.

      But one thing puzzles me – although this workflow is a “monster”, the supporting org_unit only has about 20 positions in it. 

      So I’m wondering if there’s some rule of thumb you could come up with (you could call it “Rickayzen’s Razor”), which says that a workflow is probably too complex if the ratio of subworkflows (or tasks/steps) to org_unit positions is above a certain number.

      Best regards

      • Hi David,

        Ten years on the methodology is established and ‘intuitive’ :-). But at the time it was revolutionary (like flying – “why not just jump on a horse instead” 🙂  ).

        You’ll get a more qualified answer in the bpm forum. But for starters I’d say that there’s now magic ratio and you’ll be surprised at how many steps there are in what appears to be (on the business level) a simple workflow. Taking the quirks of nature, company policy into account leads to complexity at the execution level.

        Having just a few positions sounds great (irrespective how many steps you have). The maintenance will be really simply (and cheap) if you indirect via something else (e.g. jobs, roles). Then when people leave the department or more are added to deal with bottlenecks you don’t touch the workflow – just the org structure.

        • … and I think maybe my question might have better been phrased as follows:

          If the ratio of subworflows or tasks/steps to positions is too high, did the underlying set of policies and procedures grow too complex for humans to implement except in “gatekeeper/monitor” roles?

          And if the answer to this question is yes, then the next question is whether the company is really getting bang for the buck from its “complexification”, or whether the “complexification” is just justifying a whole set of financial analyst jobs …

          But again, I think you’re correct – a workflow has to be as complex as the underlying policies and procedures it purports to capture … it’s not the job of the workflow analyst to tell a client that these policies and procedures are overkill by one or more orders of magnitude …

          Best regards