How to Stop a BusComp_PreWriteRecord

Many a times we find ourselves in a situation wherein we think our configuration is correct, but why the hell can I not see my changes. Tiny things make a big difference in Siebel and we spend hours trying to figure out whats going wrong, and more often than not its just a silly property that we may have overlooked :)...read on

When the current record of a BC has beeen modified, the user cannot step off the record without either saving or undoing the record. (Under normal circumstances, saving is done automatically when stepping off, so the user does not need to save the record manually.)

When calling RaiseErrorTest in BusComp_PreWriteRecord, or when returning CancelOperation from this event, the current record does not get saved to the database; however, it remains modified, and thus the user cannot step off the record. For the user, after clicking away the custom RaiseErrorText message, it may appear as if the system suddenly gets unresponsive as they cannot step forth and back anymore, and unexperiences users may not know how to escape this situation (by e.g. undoing the current record or by modifying the record until it saves successfully).

If, on the other hand, the script calls UndoRecord before raising an error, all changes are lost, which might lead to a negative user experience.

This is why Bookshelf recommends to not using RaiseErrorText within BusComp_PreWriteRecord.

If you observe a situation where it seems necessary to cancel an ongoing WriteRecord operation in the BusComp_PreWriteRecord event handler, then depending on your scenario you may want to consider these alternate approaches:

1. Verify the changes earlier

Some scenarios might allow verifying the changes to the current record earlier, such as in BusComp_PreSetFieldValue() or at applet level. However, consider that unless a BC field has the "Immediate Post Changes" flag set to TRUE; changes in the UI will not reach the BC (and thus not trigger BusComp_PreSetFieldValue()) until the user saves or steps off the record.

2. Verify the changes later

In BusComp_WriteRecord(), it is possible to use RaiseErrorText() since raising an error here does not cancel any pending operation - the WriteRecord already has finished. In this scenario the wrong data is already committed to the database, so either the user needs to navigate back to the record and modify it appropriately, or an internal process needs to identify and clean up the record later. (This depends on your particular scenario.)

3. Use Siebel Task UI

Siebel Task UI allows to guide the user through a set of operations before saving the result. As per the Task UI documentation, "Task UI's wizard-like user interface guides the end user through task execution, allows navigation both forward and backward within task execution, and allows task execution to be paused and resumed as needed."

This process can make use of "transient" business components, which means that the data does not get stored to Siebel tables until the task is finished successfully.

Thus the Task UI seems suitable to implement the desired two-step process of saving contact data to an external system first and then to the Siebel database.

Cheers!