Is it possible to do a Post Processing on GetList in the UBAQ Method Directive to call BO’s to update the Db for each result it returns. No tablesets or BO’s are available in Post Processing when I’ve tested it. Tablesets and BO’s are available in GetList Preprocessing but doesn’t trigger.
Is there a workaround to use each BAQ result row to update the Db?
Example: UBAQ that identifies specific order releases to then loop through all the results to Allocate those specific Releases.
Are you trying to use the default update from the system? If you are, they you probably need to change the row mod of all the rows to “U” to get it tot pick it up. So do a loop and set the row mod in your loop. (I haven’t tested this, so I’m not 100% sure it will work).
The other option is to run you own Advanced BPM update and write your own code to the the update in a loop.
No syntax errors anymore, no idea why I was getting the error or what fixed it. This was not using the Default Update but rather updating values in another table using Custom Code, but it wasn’t recognizing the BO’s or tablesets I was calling. I think setting the row mod to U would’ve worked as well if I had this code in the Update portion of the UBAQ Method. Thank you for your response @Banderson!
We are currently trying the Advanced BPM update and writing our own code,
the code is updating the fields and shows correctly in the results after I do the GetList.
But it is not persisting it to the database
I have set RowMod = “U” on each row I updated
how do I force it to persist the results to the DB ?
Thanks
Would you mind sharing what you have currently? I typically just call the business objects I want to use to do the update or LINQ depending on what I’m updating. I don’t think it would work just setting the row mod of the results row to “U”.
Calling the BO is the confusing part to us…
we’ve seen thru the forum that it’s suggested to use the advanced BPM part of the update processing for the BAQ and to use the “Invoke BO Method” widget in the BPM, but what do you pass as the TableSet to that ?
(we would be using JobEntry BO, calling either Update or UpdateExt)
Do a trace in the UI, that will list all of the methods that are called. (It’s not just update) and you’ll have to call all (ok most… it takes some experience to understand what needs to be called) of the methods.
Usually it’s a getbyID which gets the dataset that you are trying to modify. Then you make your changes, then you set your row mod, then you call update.
But like @tgeels , we can’t really help you if you don’t show us what you’ve done so far.
I’ll do my best to explain…
UBAQ subquery:
UBAQ top level:
Basically the subquery is looking for certain job operations the have a scheduled due date (which is a UD field), then based on that scheduled due date, we want to update the scheduled due date for certain other job operations.
So, the query is likely to return multiple rows…I get the concept of calling GetByID, then making changes, and calling Update/Ext, but the BPM only fires once when the query runs, correct ?
Then how do we iterate thru each record returned from the query to call the GetByID and Update methods ?
The closes I’ve got as far as success goes was to use BPM custom code to iterate thru result.Results, calculate the desired scheduled due date, which took all of about 5 lines of code…when complete they show up on screen in the query results but are not persisted in the database.
Are you suggesting that in my custom code as I iterate thru the results I call GetById/Update in the custom code ? (if so in reality wouldn’t it be easier for me, since I’m only updated one UD field, to just do a direct DB update in the custom code ?)
Thanks
Yeah, you would loop through your results. Post processing on get list will have access to the full returned dataset, you just have to be ok with the update happening anytime the BAQ is run. Certain objects in the UBAQ methods have access to all the rows, and some other ones only have access to the updated rows. Use message boxes to see when you put a BPM on those objects to see what’s available.
If you’re only updating your own UD fields, then using DB is fine. Generally using the BO is the best practice, but not all situations are the same, so you’ll have to decide for yourself.
Okay, I understand a little more I think, when you say “yes, you need to iterate thru your results” you mean in my custom code in my BPM ? …
And from what you said about post processing will then apply the updates, that implies to me that I want to iterate thru the results in my custom code in a Pre-Processing directive (currently it was set up for Post-Processing, makes sense to me why the updates weren’t sticking if I’m now understanding)
thanks
Correct.
Nope. Post processing on get list means it will do stuff after it’s gets the data. The get list method just gets the information to populate your BAQ. It doesn’t do any updating the the database.
Your custom code can send stuff to the database from anywhere (pre or post). So that being able to work has nothing to do whether you put in in pre or post.
Regular BPMs usually are pre-processing because you are modifying the data that is being sent to the update method before the method is actually doing the update. But get list isn’t a method that updates anything.
I’m sure that this is super confusing, but to understand what data is where, put popup messages in BPM’s on the diffent BAQ methods and see what information you have where.
Okay, that helps for the future understanding, appreciate it…
I did just get it to work, took the approach I was using before, custom BPM code iterating thru results…it seem obvious now but yesterday when I was trying this I was updating the UD field in result.Results as I iterated thru the rows…duh…I needed to apply the update to the database directly (or use BO calls but in my case…)
