More questions re: Batch Processing with Relationships

BLOMASKY

I have a customer BO and a sector BO. (Each customer is related to 1 sector and each sector has diff. truckCosts and Max Stops.

I have a process that looks like:

FIND Customers WHERE Customers.unshippedBMEs > 0 AND Customers.sc_TruckCost>0 AND Customers.sc_MaxStops>1

Customers.unshippedFreight =
ROUND( MAX2( MIN2( Customers.unshippedBMEs / 20000 * Customers.ps_Sector.truckCost, Customers.ps_Sector.truckCost),
Customers.ps_Sector.truckCost / (Customers.ps_Sector.maxStops -1) ) ,0)

All of the Customers.unshippedFreight attribute end up with the SAME value. Is this how things are supposed to work?

CalD

I found similar when I wrote my first serious process, figured I was doing something wrong but doing IN BATCHES OF 1 sorted mine out, the other option I tried was using FOR EACH.

I am now reading in batches of 1 is not a great idea, so I intend on revisiting this process later today...

rocketman

Create a sub process and set customers as the process input.

Your main process then becomes
FIND Customers WHERE Customers.unshippedBMEs > 0 AND Customers.sc_TruckCost>0 AND Customers.sc_MaxStops>1
Subprocess1

and subprocess1 becomes

The main process will find all the instances of customers and pass them to the subprocess one at a time. This is what I was trying to explain in my reply to your other post

johntalbott

Rocketman's approach will definitely make this work.

But I still wonder if Bruce's example "should" work as-is without having the sub-process. Meaning ... is there a bug?

BenHayat

johntalbott wrote
Rocketman's approach will definitely make this work.

But I still wonder if Bruce's example "should" work as-is without having the sub-process. Meaning ... is there a bug?

Bruce's example "should" work, I don't see anything wrong.

rocketman

"Bruce's example "should" work, I don't see anything wrong."

No it shouldn't - It's never worked like this. keeping everything in ONE place is for when you want to apply a single change across ALL the find records - like the AIM example. Find all accounts that meet a certain criteria, - close all accounts. In Bruce's case it's not a single defined change , the change is based on the content of individual records. In the AIM case, you are giving the process the details of what to change manually - Account.State='CLOSED' In Bruce's case the value of the change is determined by the existing content of an attribute, and by definition, this will be the last record put in context. The value of this object is then applied to all the found records.

In older style programming terms, what you are looking to do is effectively a For... Next loop. Calling a sub process is exactly that whereby the changes you make apply only to the record being processed according to its position in the loop. Any changes therefore can be totally dependent on the contents of the record being worked on

In any system, both approaches are useful and needed so it wouldn't be right to "fix" one at the expense of another thinking it is a bug. One of my overnight processes for instance will find all accounts where a transaction has been added during the day, do some validation to ensure opening and closing balances are correct and then applies the CURRENT_TIMESTAMP to the Account.DateLastValidated attribute to all of the found records (Bruce's example - all-in-one process.

BLOMASKY

Thanks Rocketman.

That helps me understand the limitations (not really limitations, but how Aware works) of processing multiple records.

Life is good

Bruce

johntalbott

No it shouldn't - It's never worked like this.

If this is indeed working as designed, it is not intuitive.

Updating a batch of records with a hard coded value should be a very rare thing. I would categorize it as being "almost" useless.

At the very least, the user guide needs to be updated to describe more complex scenarios.

pureist

..an enhancement which would negate having to use a subprocess to achieve record by record processing of individual records in a ResultSet of a FIND (when the processing is straight forward), would be for the FOR EACH parameter to be enhanced so it can be used in a general context in Actions.
Presently:
CREATE OrderLine FOR EACH QuoteLine WITH OrderLine.fieldX=QuoteLine.fieldX.. (if this follows a FIND (ie, is not in a separate process) it will process each QuoteLine instance found one by one.
Maybe its general usage form could be:
FOR EACH Account Account.Balance=Account.Balance+..

johntalbott wrote
If this is indeed working as designed, it is not intuitive.
Updating a batch of records with a hard coded value should be a very rare thing. I would categorize it as being "almost" useless.
At the very least, the user guide needs to be updated to describe more complex scenarios.

rocketman

If this is indeed working as designed, it is not intuitive.
Updating a batch of records with a hard coded value should be a very rare thing. I would categorize it as being "almost" useless.
At the very least, the user guide needs to be updated to describe more complex scenarios.

Sorry John but I beg to differ. Updating a batch of records in one hit is a very powerful part of the system - particularly if you have 'Rules' associated with a BO.

Consider this example.

You have a rule in your BO that says, '
find all transactions where transactions in Accounts.Transactions
Accounts.CurrentBalance = SUM Transactions.total

Usually this gets fired when you edit an account record so that the user is always looking at his up to date balance

But suppose you want to issue a reminder to delinquent accounts and want to ensure all the balances are up to date. A simple two line process is all that is required

FIND ALL Accounts
Update Accounts.
Because the Rule is in the Accounts BO, it will fire for each individual record in the FIND

You can then follow this with another simple process safe in the knowledge that all the accounts are up to date

FIND Accounts Where Accounts.CurrentBalance < 0
SEND OverdueAccountReminderEmail to Accounts

The trick is knowing when to put rules inside a BO and when to reserve them for specific processes.

AwareIM is the most powerful development system I have come across in 30 years - it just needs looking at with an open mind and a fresh set of eyes

BenHayat

rocketman wrote
The trick is knowing when to put rules inside a BO and when to reserve them for specific processes.

This is exactly what I'm going through a series of BOs that require TOTAL of children's counts. I need them to be up-to-date and yet not beat the server with ever BO change.

johntalbott

rocketman wrote
If this is indeed working as designed, it is not intuitive.
Updating a batch of records with a hard coded value should be a very rare thing. I would categorize it as being "almost" useless.
At the very least, the user guide needs to be updated to describe more complex scenarios.

Sorry John but I beg to differ. Updating a batch of records in one hit is a very powerful part of the system - particularly if you have 'Rules' associated with a BO.

Consider this example.

You have a rule in your BO that says, '
find all transactions where transactions in Accounts.Transactions
Accounts.CurrentBalance = SUM Transactions.total

Usually this gets fired when you edit an account record so that the user is always looking at his up to date balance

But suppose you want to issue a reminder to delinquent accounts and want to ensure all the balances are up to date. A simple two line process is all that is required

FIND ALL Accounts
Update Accounts.
Because the Rule is in the Accounts BO, it will fire for each individual record in the FIND

You can then follow this with another simple process safe in the knowledge that all the accounts are up to date

FIND Accounts Where Accounts.CurrentBalance < 0
SEND OverdueAccountReminderEmail to Accounts

The trick is knowing when to put rules inside a BO and when to reserve them for specific processes.

AwareIM is the most powerful development system I have come across in 30 years - it just needs looking at with an open mind and a fresh set of eyes

Your example doesn't represent updating a batch of records with a hard coded value, such as the example in the batch operation section of the user guide.

Rule 1: FIND Account WHERE Account.Balance < 100
Rule 2: Account.State = 'CLOSED'

We've established that the above only works when using a hard coded value such as 'CLOSED'. From my perspective, this sort of hard-coding is poor design and basically useless.

There is nothing in the user guide that points out that the above pattern only works with hard-coded values. So it seems logical to me that Bruce's code would work by following the same pattern.

Instead a completely different pattern (calling a process after the FIND) is required which is not the least bit intuitive or discussed as being necessary in the user guide.

Because it's not intuitive, the default "fix" per the forums is to add BATCHES OF 1 potentially creating other unintended issues.

aware_support

If you have this:

FIND BO WHERE ..
BO.Attribute = Something

If only one instance of a BO is in the context, it is always obvious what is going to happen. If there are multiple instances of a BO in the context:

The expression on the left hand side of the equality statement determines which objects the change should be applied to. Since there are multiple instances of an object the change will be applied to ALL instances of the object in the context.

The expression on the right hand side determines what to change each instance to. If this expression does not depend on an instance of a BO then this change will be applied to all instances. So this works great when you need to assign the same fixed value to all instances of a BO.

However if the change depends on an instance of a BO itself, then the behaviour is undefined because Aware IM doesn't know which instance of a BO to use when calculating the change. You could argue that it should use the same instance as on the left hand side, as this would be the most intuitive thing to do. And you might be right, but it is technically challenging and it is equivalent to doing this:
FIND BO WHERE
Subprocess

which is what you should do now and which is what rocketman recommended all along. One of these days Aware IM may become smarter...

IN BATCHES OF 1 is not a solution here.

BLOMASKY

Vlad, you said: "One of these days Aware IM may become smarter..."

Oh no! It's already much smarter and better looking than me! Please.. NO MORE!

Bruce

customaware

That was V 0.9 Alpha Bruce 😉