Hold on - this is complicated but not that mysterious.
UpdateExt processing:
UpdateExt (Update External) was created to allow records with partial data values to be accepted and processed. Clearly all the Key Fields for a record and all the Mandatory fields for a record are required and unlike Update, multiple different tables (and multiple different records) can be updated with a single call. All the records passed in to UpdateExt will cause an update to occur - while BPM may have the concept of Original Record and Updated record, UpdateExt itself does not.
Internally, UpdateExt acts like the UI Client - It find the first header record, gets the key(s) and then runs GetByID. If a record is returned, the values passed in to UpdateExt are used to update that record and then Update is called. If there is a record hierarchy - Header, Lines, Releases - and child data records were included on the call to UpdateExt, the data tree is walked and Update is called for each record “touched”.
If the GetByID does not return a record, UpdateExt calls GetNew for the header and then does the Update as above. If child records were included in the initial UpdateExt call, GetNew is called for each of those records found to be new and they are also processed as above.
As the UpdateExt logic calls the other Base Methods - GetByID, GetNew, Update - BPM on those methods will fire. In the case of calls to Update, the standard Client called pattern of an Original row and a Changed row will exist as UpdateExt is acting like a Client. There are several ways to leverage this behavior in a BPM on Update - one way is to set a BPMData variable in the UpdateExt BPM processing and then have a condition triggered by that value in the BPM on the Update method. Move your code trying to compare Original with Changed to the standard Update Method.
UBAQ Processing:
When a UBAQ is processing, it runs the UBAQ Framework. Each UBAQ is considered to be a Mini BO and on the Update Processing Sheet in the UBAQ Designer, you will see the “BPM Directive Configuration” button. When you click that, it opens a slimmed down version of the BPM Designer - already prepopulated with the Names of the Methods associated with THAT instance of the UBAQ. One of those Methods is Update and that is the Method that is called prior to the UBAQ framework calling UpdateExt. This is another possible location for your BPM Original to Changed logic (there is currently a bug where Added rows are not properly identified in this timing).
When the Mini BO Update logic of the UBAQ framework calls UpdateExt, it is only passing the data values Mapped in the “Query to Object Column Mapping” section. In this processing there is no concept of Original Record or Original Value - it is just the data to be updated by UpdateExt - one record per Updated row of the UBAQ Result set.
Wrap it up Rich -
Okay. As you can see, UBAQ processing is complicated but quite elegant. Each UBAQ has the possibility of BPM on the Methods called while processing the UBAQ. The UpdateExt method itself is also fairly elegant in that it is applying the standard UI style processing to the data it is given and each method called by UpdateExt goes through BPM - just like a client caller would. This provides you with numerous BPM Touch points - both before and after - while the UBAQ is processing.