Oracle Siebel CRM Event Model (Part 1)
This article is intended for those who are familiar with the Oracle Siebel CRM system and who are well aware of its three-tier architecture.
When designing a system, it is important to understand how it will react to various user actions: creating or deleting a business component record, clicking a button on an applet, editing a field, saving data, etc. To create an architecture that, on the one hand, implements customer requirements, and, on the other hand, will not increase costs for further support and scaling, you need to know how Oracle Siebel CRM processes each event that the user or procedure initiates.
In general, event processing within each object goes through several stages:
')
In fact, Pre-Branch and Post-Branch are stubs, within which developers have the opportunity to write their own handlers, that is, to set up their own event-handling algorithm. The choice of the branch in which this algorithm is written depends on what the standard handler does. This article examines in detail the two most frequently used events at the business component level: SetFieldValue (updating the field value) and WriteRecord (saving changes to the database).
Consider the business component Contact and its field [Work Phone #]. This is a common base field that the user can edit. Currently the Immediate Post Change property is set to this field to 'Y':
What exactly does this property, we will see later.
Next, we will consider such a script at the level of the Contact business component:
In essence, a handler is written on the Pre-Branch for the SetFieldValue event, which will be called before the standard handler. What happens when a user wants to update the [Work Phone #] field? In this case, the system should display an error and, in fact, it will not come to calling the standard handler.
It was before entering a new value:
Enter new value:
After switching to another field:
It turned out the following:
Now consider the same situation, just transfer this script to the Post-Branch SetFieldValue events:
We repeat all the same actions and see a slightly different result:
First, the new value is displayed in the error text. Secondly, despite the error that the user sees, the entered value remains in place.
From the above example, we can conclude: if you refer to the field of business components on the Pre-Branch of the SetFieldValue events, the system returns the current value of the field that was there before entering the new value. On the other hand, if you refer to the business component field at the Post-Branch SetFieldValue events, the system will return the value entered by the user.
All the above principles work in the event that the handlers for Post-Branch and for Pre-Branch will be run through the mechanism of Run-Time Events, and not through scripts.
To demonstrate this, consider the following simple validation rule (Administration - Data Validation):
Since 1 is never 0, each time the system calls on this rule, the user receives an error message, and the system stops processing the event, which at that moment was triggered. Data Validation Manager is a separate large topic worthy of a separate article. Here I will not dwell on the features of its settings.
To run this rule, you need to create an Action Set (Administration - Runtime Events) with one action. The parameters for this action are shown in the table:
As a result, the handler is ready and should be attached to the corresponding event. To do this, you need to create an Event:
In this case, the handler will be launched on the Pre-Branch of the SetFieldValue event of the Contact business components if the [Email Address] field is updated. It is important to pay attention to Conditional Expression. In its framework, the system must read the value from the [Email Address] field and make sure that the length of this value is less than 3 characters. Only if the condition is met, the handler will be launched.
Now you can check how the system will react to changes in the postal address of an individual.
Email is initially filled with siebel@oracle.com:
Enter a new value whose length is less than 3 characters:
After switching to another field:
The system did not display any error. The value remains the same. Hence, the condition Len ([Email Address]) <3 did not pass. That is, the system at that moment considered the old value in the [Email Address] field, which was equal to siebel@oracle.com, saw that the length of this value is more than 3, and did not start the handler. No error occurred, and the business component field was updated successfully.
If you now enter the old value in this field:
and go to another field:
then, firstly, the user will see an error, and secondly, the value in the field will not change. In fact, we received two errors at once: the first is a system error, the second is an error from Data Validation. If someone knows how to get rid of the first in this case, write in the comments. If we understand the principle of operation of the standard handler for the SetFieldValue event, then the result will be quite logical.
Now you can make a small change in the considered Event:
In this case, the handler is bound to the Post-Branch SetFieldValue events. Everything else remains as it was, but the behavior of the system will be significantly different.
After these changes, the system will not “swear” at entering the value siebel@oracle.com in the “Email” text field:
But if you try to enter a value less than 3 characters, the following will occur:
The user will see an error message, but the value will remain in the business component field. The error message was displayed because the length of the newly entered value was checked in Conditional Expression. But, since the error occurred at the time of Post-Branch, that is, after the operation of the standard handler, the entered value remained in place.
If the standard SetFieldValue event handler actually descends values ​​from the applet level to the business component level, then the standard WriteRecord handler drops data from the business component level to the table level. That is, the data is updated in the corresponding tables, which other users of the system can then see.
The difference between SetFieldValue and WriteRecord lies in the fact that in the first case the fields are updated separately, and in the second case, changes to all the fields go down to the database at once.
If the developer writes his handler and binds it to the Pre-Branch WriteRecord events, the system will perform all actions before writing the data to the database, otherwise writing to the database will already be done. Accordingly, if an error occurs on the Pre-Branch branch, the data in the database will not change, and vice versa, if an error occurs on the Post-Branch branch, this will not affect the standard handler and the data in the database will be updated.
Knowing this fact, you can more correctly implement the business logic. For example, Pre-Branch needs to hang up various data validation procedures to ensure that the “curve” information does not fall into the base. Notification procedures can be attached to Post-Branch. For example, set up sending Emails when an application goes to a particular stage.
The Immediate Post Change field property, in case it is equal to “Y”, tells the system that the SetFieldValue event for the corresponding field needs to be launched at the moment when the user has made changes and is trying to move the cursor to another location. If it is not set, and for most fields this is so, then the SetFieldValue event occurs as part of the handling of the WriteRecord event. That is, the system looks at what data from the applet level has not been transferred to the business component level, and for each field it starts SetFieldValue, and then WriteRecord is launched.
Considering how Oracle Siebel CRM handles events, I recommend running data validation on the Pre-Branch branch of the WriteRecord event. In this case, when a user tries to save a record created by him, the system says in which fields the data does not correspond to a specific business logic. The user makes the appropriate adjustments and again tries to save everything.
Validation of the values ​​of each field will require writing a script, since the Run-Time Event does not have access to the new value when it is on the Pre-Branch branch of the SetFieldValue event.
All the described principles are valid not only when the user makes changes through the interface, but also when the EAI integration works or just the script runs the SetFieldValue method directly. For example: bcContact.SetFieldValue (“Email Address”, “rrr@kk.ru”).
When designing a system, it is important to understand how it will react to various user actions: creating or deleting a business component record, clicking a button on an applet, editing a field, saving data, etc. To create an architecture that, on the one hand, implements customer requirements, and, on the other hand, will not increase costs for further support and scaling, you need to know how Oracle Siebel CRM processes each event that the user or procedure initiates.
In general, event processing within each object goes through several stages:
- Pre-Branch
- Standard handler
- Post-branch
')
In fact, Pre-Branch and Post-Branch are stubs, within which developers have the opportunity to write their own handlers, that is, to set up their own event-handling algorithm. The choice of the branch in which this algorithm is written depends on what the standard handler does. This article examines in detail the two most frequently used events at the business component level: SetFieldValue (updating the field value) and WriteRecord (saving changes to the database).
SetFieldValue - script
Consider the business component Contact and its field [Work Phone #]. This is a common base field that the user can edit. Currently the Immediate Post Change property is set to this field to 'Y':
What exactly does this property, we will see later.
Next, we will consider such a script at the level of the Contact business component:
function BusComp_PreSetFieldValue (FieldName, FieldValue) { if (FieldName == "Work Phone #") { TheApplication().RaiseErrorText(": " + this.GetFieldValue("Work Phone #")); } return (ContinueOperation); } In essence, a handler is written on the Pre-Branch for the SetFieldValue event, which will be called before the standard handler. What happens when a user wants to update the [Work Phone #] field? In this case, the system should display an error and, in fact, it will not come to calling the standard handler.
It was before entering a new value:
Enter new value:
After switching to another field:
It turned out the following:
 | At the initial stage, the value was the same on all three levels (adjusted for formatting, which is determined by the type of the DTYPE_PHONE field). |
 | Then the user entered a new value in the “Work #” text field at the applet level. At this moment, at the level of business components and at the level of the table, the value has not changed. |
 | After the user shifted the focus from the Work # text field, the applet triggered the SetFieldValue event at the business component level. At this point, the system saw that there is a script within the BusComp_PreSetFieldValue function, and began its execution. Within the framework of this script, the current value of the [Work Phone #] field was read, and through the TheApplication (). RaiseErrorText () function, this value was displayed. This function ends the event processing, respectively, the system did not reach the standard handler and the Post-Branch branch did not reach. As a result, the old error value is displayed in the error text, and at the applet level the new value is also not preserved. |
Now consider the same situation, just transfer this script to the Post-Branch SetFieldValue events:
function BusComp_SetFieldValue (FieldName) { if (FieldName == "Work Phone #") { TheApplication().RaiseErrorText(": " + this.GetFieldValue("Work Phone #")); } } We repeat all the same actions and see a slightly different result:
First, the new value is displayed in the error text. Secondly, despite the error that the user sees, the entered value remains in place.
 | If the system reached Post Branch, then it can be argued that the standard handler completed its execution without errors. So, from the above example, we can conclude that the standard SetFieldValue handler updates the field value at the business component level. It is important to note here that at the table level nothing has changed at this moment. You can verify this by running a simple database query. |
From the above example, we can conclude: if you refer to the field of business components on the Pre-Branch of the SetFieldValue events, the system returns the current value of the field that was there before entering the new value. On the other hand, if you refer to the business component field at the Post-Branch SetFieldValue events, the system will return the value entered by the user.
SetFieldValue - Run-Time Event
All the above principles work in the event that the handlers for Post-Branch and for Pre-Branch will be run through the mechanism of Run-Time Events, and not through scripts.
To demonstrate this, consider the following simple validation rule (Administration - Data Validation):
Since 1 is never 0, each time the system calls on this rule, the user receives an error message, and the system stops processing the event, which at that moment was triggered. Data Validation Manager is a separate large topic worthy of a separate article. Here I will not dwell on the features of its settings.
To run this rule, you need to create an Action Set (Administration - Runtime Events) with one action. The parameters for this action are shown in the table:
| Action type | Busservice |
| Business Service Name | Data validation manager |
| Business Service Method | Validate |
| Business Service Context | Rule Set Name, SBL Contact Dummy Validation |
As a result, the handler is ready and should be attached to the corresponding event. To do this, you need to create an Event:
In this case, the handler will be launched on the Pre-Branch of the SetFieldValue event of the Contact business components if the [Email Address] field is updated. It is important to pay attention to Conditional Expression. In its framework, the system must read the value from the [Email Address] field and make sure that the length of this value is less than 3 characters. Only if the condition is met, the handler will be launched.
Now you can check how the system will react to changes in the postal address of an individual.
Email is initially filled with siebel@oracle.com:
Enter a new value whose length is less than 3 characters:
After switching to another field:
The system did not display any error. The value remains the same. Hence, the condition Len ([Email Address]) <3 did not pass. That is, the system at that moment considered the old value in the [Email Address] field, which was equal to siebel@oracle.com, saw that the length of this value is more than 3, and did not start the handler. No error occurred, and the business component field was updated successfully.
If you now enter the old value in this field:
and go to another field:
then, firstly, the user will see an error, and secondly, the value in the field will not change. In fact, we received two errors at once: the first is a system error, the second is an error from Data Validation. If someone knows how to get rid of the first in this case, write in the comments. If we understand the principle of operation of the standard handler for the SetFieldValue event, then the result will be quite logical.
Now you can make a small change in the considered Event:
In this case, the handler is bound to the Post-Branch SetFieldValue events. Everything else remains as it was, but the behavior of the system will be significantly different.
After these changes, the system will not “swear” at entering the value siebel@oracle.com in the “Email” text field:
But if you try to enter a value less than 3 characters, the following will occur:
The user will see an error message, but the value will remain in the business component field. The error message was displayed because the length of the newly entered value was checked in Conditional Expression. But, since the error occurred at the time of Post-Branch, that is, after the operation of the standard handler, the entered value remained in place.
Writerecord
If the standard SetFieldValue event handler actually descends values ​​from the applet level to the business component level, then the standard WriteRecord handler drops data from the business component level to the table level. That is, the data is updated in the corresponding tables, which other users of the system can then see.
The difference between SetFieldValue and WriteRecord lies in the fact that in the first case the fields are updated separately, and in the second case, changes to all the fields go down to the database at once.
If the developer writes his handler and binds it to the Pre-Branch WriteRecord events, the system will perform all actions before writing the data to the database, otherwise writing to the database will already be done. Accordingly, if an error occurs on the Pre-Branch branch, the data in the database will not change, and vice versa, if an error occurs on the Post-Branch branch, this will not affect the standard handler and the data in the database will be updated.
Knowing this fact, you can more correctly implement the business logic. For example, Pre-Branch needs to hang up various data validation procedures to ensure that the “curve” information does not fall into the base. Notification procedures can be attached to Post-Branch. For example, set up sending Emails when an application goes to a particular stage.
Immediate Post Change
The Immediate Post Change field property, in case it is equal to “Y”, tells the system that the SetFieldValue event for the corresponding field needs to be launched at the moment when the user has made changes and is trying to move the cursor to another location. If it is not set, and for most fields this is so, then the SetFieldValue event occurs as part of the handling of the WriteRecord event. That is, the system looks at what data from the applet level has not been transferred to the business component level, and for each field it starts SetFieldValue, and then WriteRecord is launched.
findings
Considering how Oracle Siebel CRM handles events, I recommend running data validation on the Pre-Branch branch of the WriteRecord event. In this case, when a user tries to save a record created by him, the system says in which fields the data does not correspond to a specific business logic. The user makes the appropriate adjustments and again tries to save everything.
Validation of the values ​​of each field will require writing a script, since the Run-Time Event does not have access to the new value when it is on the Pre-Branch branch of the SetFieldValue event.
All the described principles are valid not only when the user makes changes through the interface, but also when the EAI integration works or just the script runs the SetFieldValue method directly. For example: bcContact.SetFieldValue (“Email Address”, “rrr@kk.ru”).
Source: https://habr.com/ru/post/235669/
All Articles