If you have questions or if you want to share your opinion about Aware IM post your message on this forum
#52015 by Jaymer
Thu Nov 07, 2019 3:53 am
I've read 2 threads where ACDC talks about using this extensively.
I'd like to... I'm sure, but the light hasn't clicked yet (unlike EXEC STRING where I immediately saw ways to use it).

1) START PROCESS Action is missing from the 8.3 Docs User Guide - wondering if thats an oversight or if its being phased out soon for some reason.

2) I have lots of "workflow" stuff to code (record set to particular status needs to kick off events, emails, record creation, etc) - wondering how I can work START PROCESS into this, if it suits it. I dunno.

If anyone could paste in some code or examples, I would appreciate it. Might help me get the 'ol noggin on the right track.

#52022 by ACDC
Thu Nov 07, 2019 8:58 am
Create a Process as you normally would and then store the name of the process in the record.
Then use START PROCESS Object.ProcessNameAttr
#52024 by Jaymer
Thu Nov 07, 2019 4:09 pm
I understand the mechanics... I wondering about what programming hassle in Aware did using the START PROCESS solve for people.
(i.e. IF I DIDN"T HAVE START PROCESS, then I'd had to do it this way)

ex: A RULE in Cust table:
IF Cust.Status WAS CHANGED TO 11 THEN Handle_Process_11
ELSE IF Cust.Status WAS CHANGED TO 12 THEN Handle_Process_12
ELSE IF Cust.Status WAS CHANGED TO 13 THEN Handle_Process_13

could be changed to:
START PROCESS Status.theProcessName + Cust.Status // But this would mean I need a Plain Text field in Status to hold the value "Handle_Process_"

Why not just: ... THEN
EXEC_STRING 'START PROCESS Handle_Process_' + Cust.Status // (Apps prior to 2018 did not have access to EXEC_STRING)

See, in 1st case, none of this even needs a START PROCESS.
Thats what I'm saying, i have not yet seen the "cool" implementation of this that makes me say "Whoa, glad Aware had that Action"
#52028 by bssxfire8
Thu Nov 07, 2019 9:29 pm
Jaymer wrote:Why not just: ... THEN
EXEC_STRING 'START PROCESS Handle_Process_' + Cust.Status // (Apps prior to 2018 did not have access to EXEC_STRING)

The only thing kinda neat thing in this particular case is that EXEC_STRING isn't necessary when using START_PROCESS.
This works: ... THEN
START PROCESS 'Handle_Process_' + Cust.Status

You could cut your rule from case 1 down to:
START PROCESS 'Handle_Process_' + Cust.Status
#52038 by ACDC
Sat Nov 09, 2019 11:12 am
I understand the mechanics...

yes I should have known that .. :oops:

I think EXEC_STRING was a new function introduced along the way, START PROCESS has always been available as far as I can remember

You could probably use it in some cases in place of START PROCESS as you say.
But in my case START PROCESS is ideal because I can create a number of complex processes and then give each one a meaningful name and then make each process available for the USER to select from a drop-down text attribute on the object

Example :
I have a Product object that becomes part of the SalesOrderlineItems , WorksOrderLineItems, etc . When a user creates the inventory by setting up each Product, the user can assign from the drop-down list on the Product what process must be run to build the sub-assembly that the product is made up off ( So the process selection is user driven at product setup time).

When a SalesOrder is taken, depending on what product is used on the SalesOrderLineitem, START PROCESS then fires off the creation of the new WorksOrder object based on the process name embedded in the Product code of each SalesOrdeLine Item

So rather than have all the rules to cater for 30 types of subassemblies on the SalesorderItem, a simple START PROCESS bypasses the overhead of rule evaluation and makes it a neat and simplified way of doing it

Also in complex rule setup (especially when leveraging object rules and chaining new objects to be created based on the newly created current object) START PROCESS guarantees the right CONTEXT is always in place

Who is online

Users browsing this forum: MSN [Bot] and 20 guests