The current REFramework template handles exceptions by closing all applications and then reopening them before checking for a stop signal or retrieving the next transaction item.
This means that applications are initialized even when the process should stop or when there are no more queue items available, resulting in unnecessary overhead.
Current Behavior
Exception occurs → Framework transitions to Init.
InitAllApplications.xaml runs (apps reopened).
Then checks:
Should Stop signal.
Retrieves next transaction item.
If the process needs to stop or no items are available, the initialization was for nothing.
Suggested Improvement
Reorder the machine states so that checks for stops and transaction availability happen before initializing applications.
Proposed Happy Flow:
Init Config (previous first run sequence in init) – Load settings/config.
Get Transaction Data – Check for stop signal and retrieve next item.
Init Applications – Only if not open and processing will continue.
Process Transaction.
Get Transaction Data – Loop for next item.
End Process – Close apps and cleanup.
Key Changes:
Split Init into two parts:
Light Init (settings/assets).
Apps Init (open/login).
Move Get Transaction Data before Apps Init.
Why?
Avoid unnecessary app initialization when:
Stop signal is received.
No more queue items exist.
Saves time and resources.
Keeps the state machine logic clean and efficient.
Another simple method, using the default REF,
I leave the InitAllApplications.xaml empty with a Comment:
“Apps opens in Process flow only if Check Apps state target does not appear”
In the Process.xaml I start each application needed:
Use Check App States for each application and if they return:
“Target does not appear” - Start the application and login.
“Target appears”, skip the Use app and login -part.
After each Check app state I invoke the actual flow for that application.
So now the apps starts after the checks for stops and transaction availability.
The applications will only open and initialize if there is a transaction in the queue.
Apps initializes on the first transaction.
If an app would crash in a flow, it will initialize again on next transaction.
No need to build a completely new REF template (i believe)
To clean things up, you could have a custom “InitTheApps.xaml” with the above checks invoked in the start of Process.xaml. The custom InitTheApps could have a Kill process feature within the “Target does not appear” to ensure resetting the app completely if there was a system exception/app crash during a run.
OK, my approach is quick and dirty and does the job for me, the Check App states takes minimal time to execute if the app is already there, and often you need those checks nevertheless. From the beginning I only initiated apps on transaction 1, without Check App States, but there were scenarios with some unstable apps crashing so i reworked it the way i described above.
I was looking at your picture and wonder about the 2 New transactions from the Get Transaction Data state. Does it go to the Init - Application state only on transaction 1?
Having System exception from Process Transaction to Get Transaction is good, that should have been in the default template from the start. So to re-init applications after a system exception in the Process state, how does the flow go to init if an app crashes?
Good question and well observed, that part is key.
One simple approach is to use a Boolean flag ShouldOpenApps:
Set it to True in Get Transaction Data when a System Exception occurs.
Set it to False in Init - Applications after the applications have been opened .
Alternatively, you can reset the SystemException variable in the Init - Applications state instead of in Get Transaction Data, so the flow naturally reinitializes apps after a crash.
