Form steps and dynamic tasks - has anyone tried it?

Kjetil Kilhavn kjetil.kilhavn at bluec.no
Thu Mar 15 04:08:16 EDT 2012 

Thank you very much for your input, Mike - it is much appreciated.


Onsdag 14. mars 2012 12.43.35 skrev Mike Pokraka:
> Hi Kjetil,
> 
> This is actually a perfectly OO-able scenario.
Which is what I was working on when I discovered that the form solution wasn't 
so dynamic after all. The scenarios are approval of various budgets. They will 
have three different scenarios, which scenario to use is determined by the WBS 
element and budget version (technically by a customizing table which states). 
The approval process is really the same for all scenarios, but the 
presentation on screen varies. 
I thought I'd be smart and create an ABAP Object class which used a data 
provider selected dynamically, and while working on that I discovered I was 
going to hit some walls.
There's also a custom report which shows the status of and some runtime data 
from active workflows. If I could manage without changing the workflow that 
report wouldn't have to be changed.

One possible solution, since the process is identical, is to extend the 
current structure and use the screen processing possibilities of the form to 
hide unused fields and set appropriate texts. The advantage is that the custom 
report doesn't have to be changed. The main disadvantage is code 
maintainability - I fear it will become spaghetti coding (no offense to 
Italians, spaghetti is good as long as we are talking about the food).

Another possible solution is to create different workflows (simple development 
and maintenance) and use the ABAP Objects approach when rewriting the custom 
report (let data be returned through an interface which can then be 
implemented for each case). The advantage of this is that it allows future 
solutions to be completely different in terms of data presentation and workflow 
process while allowing simple integration into the report. The main 
disadvantage is that I will basically have to scrap the existing solution 
completely and re-implement most of it from scratch.

Then there's two options using a common workflow with specialization in 
branches. One posisbility is having a multiple values switch to go down the 
relevant path and have the various structures in the same workflow container. 
It means the container will have a majority of empty structures in each 
instance. Another option is to dynamically select a subworkflow. In either case 
I will have to change the custom report.

> Using the simplest case where POPUP_GET_VALUES would suffice as an example:
POPUP_GET_VALUES will not suffice in this case for various reasons (in my 
opinion - for reasons such as layout (usability) and possibilities to control 
e.g. search help processing). Screens in a function group would be quite close 
to the FORMS solution, wouldn't it? The question there is how much I gain by 
using FORMS.

> - Your method has input parameters or already belongs to a class instance
> with the necessary data available
> - it builds up the appropriate parameter table for POPUP_GET_VALUES and
> calls it
> - it returns the user input back to WF
> - the task that implements the method can use dynamic texts to display
> whatever is appropriate at the time.
> 
> You think too hard :-)
Still thinking a little more, but I'm at the moment thinking that the FORMS 
provide some value and am trying to figure out how I can keep that value 
without starting down a path that turns out to be leading only to frustration.


> Regards,
> Mike
> 
> On Tue, March 13, 2012 1:39 pm, Kjetil Kilhavn wrote:
> > Tirsdag 13. mars 2012 12.24.43 skrev Mike Pokraka:
> >> Hi Kjetil,
> >> 
> >> Just my opinion, but forms are great to get something really simple out
> >> the door quickly, but the moment you need modifications you end up with
> >> copies of form steps in forks and all sorts of ugly stuff.
> > 
> > I think that description is quite close to the situation. I'll have to
> > think
> > about what to do. I've provided an estimate under the assumption that I
> > could
> > change the existing solution and wouldn't have to rewrite it completely.
> > 
> > Ohhh, the hardship a workflow consultant has to suffer.
> > 
> >> For anything
> >> beyond the simplest setups I find it easier to whip up a quick function
> >> module with dialog from scratch and plug that into a method than use
> >> those
> >> dastardly things.
> >> 
> >> Even easier if you can squeeze what's needed into a call to
> >> POPUP_GET_VALUES, then you can also make the task descriptions dynamic
> >> and
> >> have the whole thing in one task.
> > 
> > I initially thought I'd be clever about it and create a new ABAP Objects
> > class
> > which supported the various scenarios, but again ABAP Objects, dynamic
> > solutions and Business Workflow have proven to mix a bit like oil and
> > water.
> > It's possible, but takes a lot of effort.
> > 
> > Time to do some hard work: think.
> > 
> >> Regards,
> >> Mike
> >> 
> >> On Tue, March 13, 2012 10:54 am, Kjetil Kilhavn wrote:
> >> > I have not really used form steps before. There is one workflow here
> >> 
> >> that
> >> 
> >> > uses
> >> > it, and now they want some changes. I was thinking of using dynamic
> >> 
> >> task
> >> 
> >> > selection in the workflow, but it seems that is not possible.
> >> > 
> >> > Here's the scenario: The current solution displays some information
> >> 
> >> about
> >> 
> >> > a
> >> > budget to be approved. There are two amounts and some other
> >> 
> >> information.
> >> 
> >> > Now they want to change this solution so there are three
> >> 
> >> possibilities.
> >> 
> >> > Sometimes one amount should be displayed, other times three amounts.
> >> 
> >> This
> >> 
> >> > depends on the other data in the system, and it is not a problem to
> >> > determine
> >> > the proper case.
> >> > However, since the structure seems to be hard-linked to the form my
> >> > problem is
> >> > that I can not pass different structures for the different cases. Thus
> >> 
> >> I
> >> 
> >> > would
> >> > have to have all fields necessary for at least one of the cases
> >> 
> >> available.
> >> 
> >> > I
> >> > can dynamically hide the fields I don't need, but it then seems the
> >> 
> >> only
> >> 
> >> > point
> >> > left in using dynamic task allocation is to have different task
> >> > descriptions
> >> > and work item texts. The user will also have different tasks in the
> >> > workflow
> >> > inbox which can be seen by an advantage or disadvantage depending on
> >> 
> >> one's
> >> 
> >> > view.
> >> > 
> >> > With such little advantage in using dynamic task allocation it seems I
> >> 
> >> may
> >> 
> >> > as
> >> > well split the whole thing completely and have different workflows
> >> 
> >> which
> >> 
> >> > makes
> >> > the maintenance and re-testing easier if they suddenly decide they
> >> 
> >> want a
> >> 
> >> > change in one of the processes. The workflow is very small, so this is
> >> 
> >> not
> >> 
> >> > really much duplication of effort/code.
> >> > 
> >> > Please enlighten me as to whether I am making any sense, or do you
> >> 
> >> have a
> >> 
> >> > better suggestion.
> >> > --
> >> > Kjetil Kilhavn (+47 40220607) - Blue Consulting AS
> >> 
> >> (http://www.bluec.no)
> >> 
> >> > _______________________________________________
> >> > SAP-WUG mailing list
> >> > SAP-WUG at mit.edu
> >> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> >> 
> >> _______________________________________________
> >> SAP-WUG mailing list
> >> SAP-WUG at mit.edu
> >> http://mailman.mit.edu/mailman/listinfo/sap-wug
> > 
> > --
> > Kjetil Kilhavn (+47 40220607) - Blue Consulting AS (http://www.bluec.no)
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
-- 
Kjetil Kilhavn (+47 40220607) - Blue Consulting AS (http://www.bluec.no)

More information about the SAP-WUG mailing list