Callback function in Aware IM?

nhofkes

I have come across the following issue. Ideally this could be solved if I could implement some sort of callback mechanism, similar to what can be done in Javascript. Or maybe there is some other elegant solution.

The situation is as follows:
I have a BO TransactionLineItem, which can be edited in a form. The BO has various rules to check whether the data is valid or not. If there is some error, the BO's State attribute is set as 'Failed', otherwise the State can have values such as Draft, Pending, Completed etc. The edit form has a Save button, and when clicked a short process is run (which has the TransactionLineItem as input):

UPDATE TransactionLineItem
If TransactionLineItem.State = 'Failed' Then
	DISPLAY MESSAGE TransactionLineItem.Error.Message MTITLE 'Error'
Else
	DISPLAY MESSAGE ASYNCH 'Transfer saved'

(Sidenote: it seems that AIM already automatically executes the BO rules when clicking the Save button, so the first line "UPDATE TransactionLineItem" is superfluous and I have actually disabled that rule, but left it in the code fragment above to make the intent more explicit.)

The problem here is that the BO rules are executed concurrently with the process. So while the rule engine is working through the BO rules, the next step of the process is also run and the check "If TransactionLineItem.State = 'Failed' " returns False because by that time the BO rules have not yet determined the error and set the flag to Failed. It's not that the BO rules take a lot of time, probably only a fraction of a second, but I can see in the log that the calling process is already progressing and using the 'old' data from the BO.
To solve this, either the second line should only be executed after the BO has been fully updated (all BO rules processed and attributes updated), or you would need a mechanism where the next step (or probably separate process) would be called automatically upon finalizing the BO update (i.e. callback).

In theory I could probably integrate the user feedback into the BO rules, or call the communication process from the BO rules, but these approaches are not really consistent with the principle that BO rules should not interact with the user directly.
I could also use a Session BO and put the required communication steps there (e.g. in a text variable which can then be executed via EXEC_STRING) and trigger that by having the TransactionLineItem set a flag in the Session BO once it is fully calculated, but that is very tricky and can quickly result in concurrency issues if several objects are processed simultaneously.

Any ideas?

hpl123

2 things you can try are:

Have the BO rule "work" in the process as well i.e the process do the work you really wanted the rule to do (check and set status failed etc.) which means your process get/has the right data and the BO rule would execute and check and probably either do the same thing the process did or do nothing. Not sure if this works in your scenario but try it.
Play around with priorities for the rules i.e you can "delay" (or make quicker) the BO rule execution.

nhofkes

Thanks for the suggestions.
As to the first: I thought about that, but it would imply duplicating some of the BO rules into the process. With the risk of getting differences between those two rule sets, and increased maintenance.
On the second: I already set the rule priorities to make sure that error checking is done pretty much at the start of the rule evaluation. I don't think that I can gain much there.

PointsWell

I have had a similar problem before where rules need to be controlled in their execution and I used an attribute with a number.

IF BO.Check was changed to 10 then xyz BO.Check=20

IF BO.Check was changed to 20 then abc BO.Check=30

Then your process can be called or stopped if BO.Check doesn't get to the required number of checks. Or the button could set the BO.Check to 40 and the business rule

IF BO.Check was changed to 40 can then trigger the process

aware_support

How do you start the process in the first place? Is it started directly from the click of the Save button?

The Save operation has an option to start the process after the form has been saved. Are you using that option? If not, you should.

There is also a possibility to start a process via Javascript when the button is clicked. In this case you can use some kind of a callback mechanism as well.

nhofkes

aware_support wrote
How do you start the process in the first place? Is it started directly from the click of the Save button?
The Save operation has an option to start the process after the form has been saved. Are you using that option? If not, you should.

Sorry, I wasn't very exact in my description. It isn't really a Save button (button with a Save operation) on a form, but a row operation defined on a grid ('operation with records') defined as 'Start process'. I found that when such a row operation is executed, the rules of the BO are automatically executed (triggered), which is good. The only problem is that the execution of the process (defined for the 'Start process' operation) doesn't wait until those BO rules are fully processed, so it doesn't use the updated BO values.

aware_support wrote
There is also a possibility to start a process via Javascript when the button is clicked. In this case you can use some kind of a callback mechanism as well.

I am not sure that this will solve the issue. I understand that I could start an Aware process from a Javascript call and could then wait until the process is terminated. But that is not the same as initiating the execution of BO rules and waiting for those rules to finish before continuing with a process that uses the outcome of those rules.

aware_support

"I found that when such a row operation is executed, the rules of the BO are automatically executed (triggered), which is good."

No, they are definitely not executed automatically when a row operation is started. If the process that you start modifies the record, then yes, the rules are executed for the record, but this is done synchronously - the next action of the process only starts when the rules finish.

What makes you think that the rules ARE executed in parallel with the process?

nhofkes

This is a grid on a form, with row operations defined for the grid. The form is for the Transaction, the grid shows the line items for that transaction. When the row operation is executed, I can see in the Testing Log that the rules for the TransactionLineItem are being executed.

aware_support

Can you attach your rule log?

Can you try turning "No auto-refresh" on (property of the operation that starts the process)

nhofkes

Testing Log below. You can see the line "Updating business object TransactionLineItem" before the line "Executing process TransactionLineItem_Update". In fact, some of the lines relating to the BO rules appear after the line "Executing process TransactionLineItem_Update", which seems to indicate that the BO rules are executed in parallel with the execution of the process.

"No autorefresh" is already turned on.
Screenshot 2024-08-12 114851.png

Screenshot 2024-08-12.png

aware_support

There are two processes - Transaction_Edit and TransactionLinItem_UpdateWithConfirmation

Which one are you starting? What are the rules of the process?

nhofkes

aware_support wrote
There are two processes - Transaction_Edit and TransactionLinItem_UpdateWithConfirmation

Which one are you starting? What are the rules of the process?

The process started from the row operation is TransactionLinItem_UpdateWithConfirmation (see also the earlier screenshot).
That process is defined as:

If TransactionLineItem.State = 'Failed' Then
	DISPLAY MESSAGE TransactionLineItem.Error.DisplayMessage MTITLE 'Error'
Else
	DISPLAY MESSAGE ASYNCH 'Transfer saved'

Initially, I had as the first process step the following line:

UPDATE TransactionLineItem

But I had disabled that because the BO rules already execute automatically when the row operation is started, so the UPDATE only resulted in the BO rules being executed twice.

Jaymer

FWIW, it will be 6+ hours before Vlad replies... so:

1) I'm not sure what BO you're talking about when you mention these rules being executed. I can tell you from experience thats its not clear enough for Vlad - trying to understand your issue requires reading back through many posts and it becomes unclear. Esp. because once it was a button on an Edit form, and now its a Row Operation Start Process.

I can only suggest to start over with a specific and clear example - trying to help - take it with a grain of salt.

2) Using that Log in the picture:
Editing Transaction 9259
A new rec gets created (the -1 ID) - unsure what that is
An Edit & Save (not a create) of LineItem 9261
Rules run for the Update of LineItem (all that blue stuff is just noise in this analysis)
The Process "with conf" is called, and gets the LineItem & Transaction in context (NOTE: Both of these records are physically re-read from disk when the process starts)

In your post, I don't understand this:
Sorry, I wasn't very exact in my description. It isn't really a Save button (button with a Save operation) on a form, but a row operation defined on a grid ('operation with records') defined as 'Start process'. I found that when such a row operation is executed, the rules of the BO are automatically executed (triggered), which is good. The only problem is that the execution of the process (defined for the 'Start process' operation) doesn't wait until those BO rules are fully processed, so it doesn't use the updated BO values.

And when you reference your log, unless I print this out and mark it up, its very hard for me to see this:
"You can see the line "Updating business object TransactionLineItem" before the line "Executing process TransactionLineItem_Update". In fact, some of the lines relating to the BO rules appear after the line "Executing process TransactionLineItem_Update", which seems to indicate that the BO rules are executed in parallel with the execution of the process."
Sorry, I don't see. Annotating the image is a lot more helpful.
And again, from experience, without putting words in Vlad's mouth, he's not going to see it either.

So, unless you want to waste another 1/2 day or day and not get a useful response tomorrow morning, I can humbly suggest you re-state and clarify. I just don't see the issue. Save rules fired... process got called... seems fine.

Jaymer...

nhofkes

Thanks Jaymer. Below is the same picture but with annotations. I hope this helps.
Vlad writes that BO rules "are definitely not executed automatically when a row operation is started.". In my application, for some reason, I see the opposite, the BO rules are evaluated whenever a row operation is selected and regardless of the actual contents of the process.
As mentioned before, I am referring to a row operation for a grid that is displayed on a form.
I will see if I can put together a small BSV that demonstrates this behaviour.

Screenshot 2024-08-12.png

Jaymer

Suggestion:

Create a process 'dummy' with 1 line that does nothing , like a DISPLAY MESSAGE 'x' , but then disable it

Call 'dummy' instead of your existing process and see what the log shows.
Use NO INPUTS in dummy.

nhofkes

I did as suggested. I already had a similar 'dummy' process which I had called 'Void' - I needed this in some other areas. That process has just one rule, but that rule is disabled. The process has no

I then created another row operation "Start process" which calls this 'Void' process. And believe it or not, the same situation happened as before: the BO rules were being executed promptly upon clicking the "Dummy" row operation (and in fact simultanous with the execution of the dummy process itself).

I should perhaps add that this row has inline editing, and that I select the row operation after having made some edits in the line. So the 'dirty' flag for the line is set (as marked by the small black triangle in the left upper corner of the cell). Most likely, in this situation the changes to the line item are being saved (causing the BO rules to execute) automatically when a row operation is selected.

nhofkes

I had a look in the queryLayoutParser.js file, which confirmed what I had suspected. See code below copied from that file (lines 5044-5069 in v9.0 build 3272):

runItemOperation: function (link)
{
	var link = $(link);
	// operation is in a special attribute of the link
	var operIdx = link.attr ("data-operidx");
	if (! this.m_itemOpers || this.m_itemOpers.length <= operIdx)
		return;
	if (this.m_editingMode == "incell")
		this.saveInlineEditChanges();
	var oper = this.m_itemOpers[operIdx];
	var row = link.closest("tr");
	this.doRunItemOperation (this.getWidget(), oper, row);
},

This function runItemOperation is called whenever a Row Operation is initiated. The relevant portion here is the line

if (this.m_editingMode == "incell")
this.saveInlineEditChanges();

(Note that what in Aware describes as "inline editing" is in fact what Kendo calls "incell editing").

And here is the function saveInlineEditChanges and related function saveInlineEdits (lines 4069 - 4102 in v9.0 build 3272):

saveInlineEditChanges: function ()
{
	this.saveInlineEdits ("save");
},

saveInlineEdits: function (mode, ctx)
{
	var grid = this.getWidget();
	if (! grid)
		return false;
	if (this.m_pendingSave || ! grid.dataSource.online ())
		return false;   // saving already
	if (grid.dataSource.hasChanges ())
	{
		this.m_pendingSave = { rowIdx: this.m_curEditedRowIdx, mode: mode, ctx: ctx };
		this.m_recalcAttrName = null;
		// failure is handled by data source error
		grid.dataSource.sync ();
		return true;
	}
	else if (this.m_wasRecalculating)
	{
		this.sendEvents(grid);
	}
	this.m_wasRecalculating = false;

return false;
},

The line "grid.dataSource.sync ();" saves the changes in the grid to the server, which causes the BO to update.

As mentioned before, in itself there is no problem that the BO is recalculated. It's just unfortunate that this update is apparently simultanous with the process being executed, instead of first finalizing the changes to the BO (including evaluation of all BO rules), and only then executing the process.

aware_support

Jaymer is right - you need to provide a little bit more clarity.

From your log it seems that the Update operation is executed as a request from the user interface AND that the process invoked from a row operation is executed AFTER the update. This means that something is happening before the process starts - this is where you need to focus. There is the Transaction_Edit process that is suspended just before the object is updated. What does this process do and why is it suspended?

I know for a fact that the rules of the object are NOT executed automatically when a row operation is invoked. And for a particular user everything happens synchronously unless they somehow manage to click several buttons in quick succession.

See if you can reproduce this in a small application - I doubt that you will.

nhofkes

aware_support wrote
I know for a fact that the rules of the object are NOT executed automatically when a row operation is invoked.

Strictly speaking, yes. Invoking the row operation does not in itself result in execution of the object rules. However, the situation is different when the row operation is on a grid with inline editing enabled AND such edits having been made in the row when the row operation is invoked. In that case, when the row operation is invoked, the changes in the grid row (incell edits) are saved (synced with the datasource), resulting in a change in the object that is displayed in that particular row and therefore trigger the object rules to execute.
Thus, invoking the row operation results in saving the changes in the grid which triggers the execution of the object rules.

aware_support wrote
And for a particular user everything happens synchronously unless they somehow manage to click several buttons in quick succession.

According to the log, in this specific situation the object rules are executed at the same time (in parallel) as the execution of the process that is called from the row operation. Also if just one button is clicked. I believe this is caused by the fact that the call to grid.dataSource.sync() is an asynchronous operation.

aware_support wrote
See if you can reproduce this in a small application - I doubt that you will.

Yes, I will put that together.

aware_support

I see - inline editing was the detail that I missed. With inline editing on, what you are saying is most probably true. I will investigate tomorrow what you can do about it.

If you prepare a small BSV that would save me some time.