by using a special naming convention in the filter name. When you create or modify the filter, its name must end in a back quote character [‘] followed by an exclamation point [!]
You can break up the Filter into two childs....
->The first one will be having the Push Fields action with the overriding concept (`!).
->Second filter will have the set field action.
->The execution order of PUSH field action filter should come ahead of the set field action filter.
I use a number of `! processes for my Push Fields actions with intent to get data processed in advance of specific Set Fields actions required for for the Push Field actions. This is successful.
However, I have a SET FIELDS action I want to occur after former data is committed. Right now, the data evaluated in SET FIELDS references the database values -- not the most recent values (whether that be database or transactional).
I do have my processes set up as you suggest.
-- Filter 1: Push field to existing record using display-only fields
-- Filter 2: Set fields based on data provided in Filter 1. Correct value is calcaulated
-- Filter 3: Set field (SQL to get SUM) from records (inclusive, but not exclusive, of record affected in filter 2)
This filter 3 does not see the resulting calculation in filter 2. My filter logging clearly shows the filter 2 operation correctly sets the value, but it appears filter 3 references the value from database instead of transactional value.
Might it be possible to execute a SET FIELDS in a Run Process command via filter?
Below is representation of work flow occuring...
Note the value set: 18,068 (transactional value)
Later a Set Fields using SQL sees: 30,117 (database value)
> Checking JOIN:Service_CustDowntime:UpdateDowntime:RestoreTimeNoChange (500) > --> Passed -- perform actions > 0: Set Fields > Downtime Minutes (720200006) = 18,068 > MTTR (720200007) = 2.01 > /* Tue Sep 07 2010 09:22:17.0240 */ End of filter processing (phase 1) > Checking MOD:TRB:OnMod:ProcessDowntime:Summary (955) > --> Passed -- perform actions > 0: Push Fields > <deferred to phase 2> > /* Tue Sep 07 2010 09:22:17.0390 */ End of filter processing (phase 1) > /* Tue Sep 07 2010 09:22:17.0390 */ Restart of filter processing (phase 2) > /* Tue Sep 07 2010 09:22:17.0390 */ 0: Push Fields > <deferred from filter MOD:TRB:OnMod:ProcessDowntime:Summary> > +chk-GetNewValues (720200008) = 0 > /* Tue Sep 07 2010 09:22:17.0400 */Start filter processing -- Operation - SET > DF:TRB_DowntimeSummary - 000000000000082 > Checking DF:TRB_DowntimeSummary:OnMod:GetSUM`! (500) > --> Passed -- perform actions > 0: Process > Application-Release-Pending > 1: Set Fields > Downtime_Svc_Analog (720200011) = 30,117 > 2: Set Fields > Downtime_Svc_Digital (720200012) = 0
A direct SQL will always reference data directly from the DB.
For each Filter that you want to execute in order, and bypass the phasing, you need to add the "`!" to. It may require you to break out each operation into its own Filter to get it to fire correctly and in sequence (inlcuding the release application pending).
Even though you show a Phase 2 operation as being completed, the whole transaction for the record (all Filters etc) are subject to the Filter phasing.
I'll separate each of the remaining actions into their own filter.
I don't think I will need the "Application Release Pending" operation. I believe the Push Fields `! will do the trick.
You will need Application-Release-Pending. Just using the `! with the Push Fields will not do it.
To quote the workflow guide "You can override phasing for Direct SQL, Notify, Run Process, and Distributed Server Option actions. If you override Push Fields actions, the actions take the intermediate values, but the database transaction is deferred."
With what you're describing, the Push Fields' database update is still in Phase 2, after the Direct SQL you moved to Phase 1! You can see this in the SQL/Filter log. I have encountered this before, but at the time I did not have the Application-Release-Pending available as an alternate solution.
If you must use the Direct SQL with the Pushed data, you'll need to use Application-Release-Pending to also move the Push Fields database operation to Phase 1.
To operate 'Application-Release-Pending', it appears I execute as Run Process in 1st action of filter. Does this then release for all subsequent actions in same filter?
no, it will only release the current transactions that are pending. You will need to run it again at a later stage to release other transactions.
This seems to do the trick.
Instead of moving action to phase 3, it instead releases the transitional (intermediate) data immediately and makes it available for subsequent processes.
My only concern at this point is whether my system has processes contingent on processes occuring in proper order. I'll look into that.
Thank you very much!