Need Ideas to build a huge approval process workflow.

[grocha]

The macro workflow itself is not huge at all, the problem is the amount of conditionals I have to create.

The basic flow of the WTDocuments is: After creation, depending on the metadata of the document, one or more people has to comment the document, then a consolidator has to consolidate the comments and send it outside the company, the same will repeat when a new revision of the document is created.

The problem is that depending on 4 attributes combined- one of them with 119 different possible values - a document may pass through too many different routes, as the company is huge and theres a lot of people involved in this process, this would work almost like the "subscription" function by user, there's so many people that I probably can't create so many roles to handle it.

It would be like:

"attr1-attr2-attr3-attr4-COMENTATOR" multiplied by the number of possible combinations...

"attr2-CONSOLIDATOR"multiplied by the number of possible combinations, less consolidators at least...

The problem is this distribution of commenting activities, and to make things worst, there may be more than one person commenting documents per combination and it's an "AND" conditional, that means wathever the amount of people commenting that combination, all of them has to pass to the consolidator.

I'm trying to think outside of the box to solve this with less effort possible and making the maintenance of it easy too, any ideas will be greatly appreciated

Guilherme Rocha

[g_prajeesh]

Hi,

May be the new Business Rule Functionality can help you to resolve this I
believe

Regards
Prajeesh Kumar


On Fri, Jul 18, 2014 at 8:40 PM, Guilherme Rocha <->
wrote:

> The macro workflow itself is not huge at all, the problem is the amount of
> conditionals I have to create.
>
> The basic flow of the WTDocuments is: After creation, depending on the
> metadata of the document, one or more people has to comment the document,
> then a consolidator has to consolidate the comments and send it outside the
> company, the same will repeat when a new revision of the document is
> created.
>
> The problem is that depending on 4 attributes combined - one of them with
> 119 different possible values - a document may pass through too many
> different routes, as the company is huge and theres a lot of people
> involved in this process, this would work almost like the "subscription"
> function by user, there's so many people that I probably can't create so
> many roles to handle it.
>
> It would be like:
>
> "attr1-attr2-attr3-attr4-COMENTATOR" multiplied by the number of possible
> combinations...
>
> "attr2-CONSOLIDATOR" multiplied by the number of possible combinations,
> less consolidators at least...
>
> The problem is this distribution of commenting activities, and to make
> things worst, there may be more than one person commenting documents per
> combination and it's an "AND" conditional, that means wathever the amount
> of people commenting that combination, all of them has to pass to the
> consolidator.
>
> I'm trying to think outside of the box to solve this with less effort
> possible and making the maintenance of it easy too, any ideas will be
> greatly appreciated
>
>
>
> Guilherme Rocha
>
> “A goal without a plan is just a wish.”
>

[AL_ANDERSON]

Try to think in terms of Groups where you create one group for each
distribution condition or department that can then map to distribution
conditions. You can make many 10s or 100s of groups - just depending on
how much set up and maintenance you want to put into the system set up.

If you wanted to, you could even name the groups,
"attr1-attr2-attr3-Group" so that it very clear what named group of users
gets notified for what combinations of attribute values.

You can route things from group to group if you use a code snippet to
assign a task to a group based on the attribute values and group names.
You can e-mail groups based on logic of any kind.

As for consolidating the comments, you will just have to write a program
to recursively loop through comments by attribute and consolidate them in
whatever format you want, either in a code segment called out by the
workflow, or maybe as a link in the e-mail that runs a JSP that in tern
runs in real time for the user.

You might get crazy and use nested groups to collect groups of people by
attribute that gets collected and distributed to that group. For example,
maybe "attr1-Consolidator Group" that has, as its members, all of the
Groups that include "attr-1" in the group name so your API could navigate
from the attribute to the group to its subgroups easily.

Something along these lines might help.

Al

[MikeLockwood]

Fundamental challenge - having different parallel paths thru the workflow template for each process.

Attached is one attempt that I made at describing this a while back and our current (crude but effective) approach. On the 2nd tab, see the structure for each Role (could be used for any other path as well); each is dependent on a condition which uses variable values / code determined previously in the process.

[avillanueva]

Try to see if there is a way to use variables and groups so that you can generalize the workflow elements that are common.

[grocha]

Thank you all for the ideas,

I ended up narrowing down the process and reducing the amount of groups needed.

As a regular user is who will keep the people to be notified up to date, I opted to use roles other than groups as it’s easier for she to manage the roles, 314 roles where created.

We created a jar file containing code which reads a text file containing the rules of the distribution in the format “attr1|attr2=role” and keeps it in cache for 5 minutes then re-reads the file again (this is to reduce impact in processing).

The text file containing the “from-to” rules ended up like this:

attr1|attr2=role

attr1|attr2=role

attr1|attr2=role

…

This way the code required in the workflow to perform the route is minimal, I just read the attribute using the new “PersistableAdapter” to get the attributes, pass it to the method in the jar which returns me the result of the conditional directly, this result is the internal name of the role which will receive the notification and activity, I put it in a variable and use it in a notification and an activity.

It was fun.

Guilherme Rocha