How can I compare pre and post update field values in custom assembly event handlers

I'm having an issue using the custom assembly event handlers to determine if a specific field has been updated. What I need to do is during an update operation, see if one specific field was changed, and perform some logic if that has occurred, but I can never seem to retrieve the original value.

In the PreUpdateCollection and PostUpdateCollection events, I've defined

updateRequest = (UpdateCollectionRequestData)args.RequestPayload;
updateResponse = (UpdateCollectionResponseData)args.ResponsePayload;

For PreUpdateCollection, the updateRequest collection contains the fields NEW field value, not the original, and the updateResponse is NULL (as I would expect).

For PostUpdateCollection, the updateRequest and updateResponse both contain the NEW field value, so I cannot compare the original value vs a potentially updated value.

I've also tried the PreItemUpdate and PostItemUpdate and it's essentially the same behavior.

Is there a way, using the Event Handlers to ever see the original data state?

Find more posts tagged with

Accepted answers

Stephen Cena

#SMH - Yes, it's a custom assembly. Helps if I read.

You can use the AES to do the initial testing & then have your IDO custom assembly handle the heavy lifting if the conditions are met.

All comments

Stephen Cena

Depending on the version of CSI you're on, you might want to leverage the Application Event System first. I've used it to do what you're asking in numerous cases. Ex: Notify Cost Accounting if a PMT code is changed from 'T' to 'P'.

Is that code in the FormScript or an IDO Extension Class/IDO Custom Assembkly?

Stephen Cena

#SMH - Yes, it's a custom assembly. Helps if I read.

You can use the AES to do the initial testing & then have your IDO custom assembly handle the heavy lifting if the conditions are met.

Legacy Contributor

That is the one thing about the IDO Extension Class event handlers that is different from the AES equivalent ones. For whatever reason, AES event handlers have the ability to look at before and after values, but the IDO Extension Class ones do not, unless there is some function/object at the IDO Extension Class layer that provides that functionality, that I am not aware of. If that is indeed your need, than as Stephen suggests, you would have to start off in an AES IDO event handler and then drop to an IDO Extension Class method to handle the rest of your logic.

Legacy Contributor

Stephen/Tim,

Thank you. I was able to get it working using the AES to fire a custom assembly to do all the work.

BradleyBrown

I was trying to get back to my desk so I could respond but now I see Stephen was able to help you out. Very excellent.

Just in case anyone is interested, you can do this in the PreUpdateHandler in code by performing a load collection request against the IDO in question. You could base filtering on property values in the update collection request if need be. Then iterate over each collection to perform your comparisons. You could then modify the update collection request if necessary before sending it on to be processed.

Legacy Contributor

I believe the question would be, is the instance of the IDO Extension Class the same one for both the pre and post update handlers? If so that would let you pass the pre update handler collection to the post update handler collection. If not, you would have to store the pre update handler collection somewhere the post update handler could access when it fires.

BradleyBrown

The UpdateCollectionRequest passed to the pre update handler contains the changed dataset.

Performing a load collection in the pre update handler returns the current dataset, prior to changes having been applied. I wanted to be sure of this before commenting, so wrote some quick code and ran a debug session, breaking after the load collection. Verified it works as described.

Legacy Contributor

So, this worked perfectly as well, and kept everything code without needing to involve AES. I can actually perform all the actions I need in the Pre-update trigger, because I have both the old and new values using the LoadCollection. All the actions I take here are still rolled back if there's a failure in the actual save or in the Post update trigger (I tested that to make sure). So instead of using the Post Update to do my actions after everything is committed, I can use the Pre Update and just assume the steps after this will save correctly. If there's a failure anywhere along the way, everything gets rolled back properly.

BradleyBrown

I was curious about this so ran a quick test. If you serialize the loadcollection object instance into, say, a json string:

string x = JsonConvert.SerializeObject(response);

You can store that in an applicationdb session variable and recall it in another method or handler. You could then deserialize the json into a new load collection response instance:

LoadCollectionResponseData y = JsonConvert.DeserializeObject<LoadCollectionResponseData>(x);

Obviously I am using json.net here.

Copyright © 2025 Infor. All rights reserved.