If the process runs on an error after setting the value, the content of the variables within the single instance codeunit is preserved and no rollback is performed on the variables.
I suggest to create the possibility to introduce a new property "RolleBackAtError = true" (Default value = false) in a Single Instance Codeunit. If the property is set, the content of the global variables should be reset (maybe only the support of temporary record variables would be sufficient here).
This way you could achieve that no "dirty reads" on the stored variable values from other processes would be possible.
Comments
Category: Development
Any "session scope" solution does not solve this problem. "Session Unique ID" is assigned once at the start of the session and does not change. OnAfter... events do not help because if error happens they might not be called (it depends on how the code is structured). OnBefore... events do not help because you want to clean up after the operation has completed.
We need to distinguish separate "actions" happening within a session. Something like global GlobalOperationId (Guid) that would be created at the start of each AL code invocation and would not change until the operation ends.
GlobalOperationId should be also assignable to help distinguish operations happening in the single user action, e.g. batch posting or some complex integration that does many different things like creating documents, posting, etc.
Category: Development
@Business Central Team (administrator)
Can you please include in your roadmap as this functionality is very required for transaction process.
Category: Development
@Lorenz good point (my solution only works if there are no commit commands in the transaction pipeline)
Category: Development
@Steve: We tried too to write variables to a temporary table. It does not work if the procedure is followed by a request page because a COMMIT is required after inserting a record (in a temporary table too).
Even better to set variables in a single instance CU would be, to have the call stack from where a function is called from. On-Prem we use a dll to do that.
Category: Development
I don't think this feature request is necessary.
This can be accomplished via a table to temporarily write/read/clear store session-level variables. It's how I accomplished this safely without having to rely on single instance codeunits (for the reasons you noted - no rollback in SI CU's)
The primary key fields is as follows:
- Record Key (I made this an extensible enum) - this is used to define what kind of value is stored in the record (e.g. enum::"Sales Order No.")
- Session Unique ID (this is the GUID that BC assigns to every session)
The remaining fields in the table store any any one value datatype (integer, text, decimal, boolean, datetime, recordid, guid, etc).
With it, I can clear+set a custom value into that before a posting routine is called, then fetch that value via the posting routine's event subscriber. If an error is thrown, the table change is rolled back (provided there is no commit in the code). If there is no error then I clear the record.
That said, I do believe that the Base Application needs to support this kind of functionality, especailly now that the ability to pass global vars in an event has been killed off.
Category: Development
Business Central Team (administrator)
Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we might consider it in the future.
Best regards,
Business Central Team