15 Variable limit for WFWK.1 - LawsonGuru.com

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

George Graham

Veteran Member

Posts: 201

2/9/2012 4:42 AM

Have a custom design studio form that is consolidating functionality. The form needs to kick off a process flow that does several things and updates multiple other tokens. The form writes out some of the data to the token it is built on, but a number of fields are not stored in the primary token and tables - and it exceeds 15 values, which appears to be the limit in WFWK.1. Therefore I can't just pass in the data through the variables in WFWK.1

The only option that I can think of is to use a custom table that I make visible within process flow that can be used as a temporary storage container, create a basic paint form on the custom table, then do the form against this table and have the DS write out the data - and then call a process flow that will then read this data in and go from there.

I don't want to call multiple flows from DS as there are some dependencies and flows would have to complete before the next one starts - so holding the form hostage while flows complete is not a good option.

Anyone else run into this issue? Options? Thoughts?

David Williams

Veteran Member

Posts: 1127

2/9/2012 2:03 PM

George,
Lisa Parsons shared a DS script with that she wrote that will write out more than the 15 variables that WFWK accepts - but another option is to add the additional ones you need to the WorkUnit Variables once the original WorkUnit is created. Are you actually using WFWK.1? You could modify it to accept the additional fields you want and once you've added the WorkUnit you could trigger a quick flow file to add the additional variables.
Either solution seems easier than creating a custom table that you'd have to query within the flow anyway.

George Graham

Veteran Member

Posts: 201

2/9/2012 4:45 PM

No - the DS form is actually built on PA31 as a precursor to PA52.4 (Hire and Applicant) - but there are a lot of other fields that are being collected that need to be "passed" on to the employee once they exist.

I'm aware that once the work unit exists we can add variables pretty much unlimited - but its initiating the ags call from the DS to WFWK to get a work unit, then coming back to the DS and tell it what that work unit is that seems to get tricky - and lots of points of failure to trap and route....I'll see if I can find her script as a starting point....

George Graham

Veteran Member

Posts: 201

2/9/2012 4:54 PM

Out of curiosity - I can see how the flow would write out the additional variables into WFVARIABLE - but then how from DS would I update all of those additional variables?

David Williams

Veteran Member

Posts: 1127

2/9/2012 5:11 PM

I'll find Lisa's script and send it to you.

David Williams

Veteran Member

Posts: 1127

2/9/2012 5:33 PM

George - send me your email please. David@ConsultDavidW.com

George Graham

Veteran Member

Posts: 201

2/14/2012 11:18 PM

FYI - trying to report back to all. To summarize the procedure that does work: Submits the process flow that does the initial pass to simply create the workunit. That passes back the workunit number to DS where we can then issue the bpm/WorkUnitVariablesForm.do to update as many variables as needed. Then issue a release to the workunit to start it back over - this time having it take the correct path since the variables all have a value.

*** HOWEVER *** - the "gotcha" in this is that the submission of the variable values and the workunit release make calls to bpm forms - which means that the person logged in to the DS form has to be a process flow admin otherwise it returns that error message that they do not have access.

So....any creative ways around this one?

sVaye

Basic Member

Posts: 10

2/22/2012 5:21 PM

Have you considered passing the needed keys to the process flow and having it create its variables via the bpm/WorkUnitVariablesForm.do?

Shane Jones

Veteran Member

Posts: 460

4/22/2012 12:42 PM

I have a similar project and I was thinking I would just trigger two flows. Then I can have one flow end after it shares information with the other flows... This should allow me to use 29 variables (1 variable will be sent to each flow so I can ensure I am linking the right flows together.)