Form steps and dynamic tasks - has anyone tried it?

Kjetil Kilhavn kjetil.kilhavn at bluec.no
Thu Mar 15 04:40:57 EDT 2012 

OK, enough thinking I believe. In order to not risk introducing errors in the 
existing solution I think the following is the best solution:

Don't touch the existing solution (BOR-based)
Create a new workflow for each scenario using FORMS (ABAP Objects-based)
Create an interface for the custom reporting and implement this for the new 
and old solutions.
Rewrite the custom report to retrieve data via interface references.

I think that's an OK balance between reducing risk and having maintainable 
solutiuons. With one workflow per scenario the workflows become as uncomplicated 
as I can manage to make them. One task per scenario is an advantage in that 
the work item text and task title and description can be made specific, the 
only disadvantage is that when viewing tasks per type they will have three 
instead of one group for budget approvals. That can be defended as it is in 
fact three different types of budget approvals - even if they have identical 
approval processes.
Using ABAP Objects and reporting via interface I leave the door open for 
future scenarios.

Unless someone tells me this is an idiotic decision I will stop thinking :-)

Torsdag 15. mars 2012 09.08.16 skrev Kjetil Kilhavn:
> 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