Form steps and dynamic tasks - has anyone tried it?

Mike Pokraka wug at workflowconnections.com
Fri Mar 16 06:05:20 EDT 2012 

Hi Kjetil,

Sounds like you're looking at all angles.

I might mention that I just used POPUP_GET_VALUES as an example. Nothing
stopping you from putting your own dialog FM together, the idea remains
the same - dynamic control from a single method.

As to the reporting angle, I often use BOR and OO versions of the same
object in the same WF for compatibility reasons. I don't know how your
stuff works, but from a simplistic view I would:
1. rip out the form step
2. Create an OO class to represent the same object
3. create a FM to do the form dialog
4. Plug FM into a data entry method on the class
5. Add new OO object info WF and put dialog step where the form step was

As I said, it's a simplistic view and there are many ways up a mountain...

Have fun,
Mike



On Thu, March 15, 2012 8:40 am, Kjetil Kilhavn wrote:
> 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)
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>

More information about the SAP-WUG mailing list