Oracle Siebel CRM Event Model (Part 1)
- Tutorial
- Recovery mode
This article is intended for those who are familiar with Oracle Siebel CRM and who have a good understanding of its three-tier architecture.
When designing a system, it is important to understand well how it will respond 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 exactly the architecture that, on the one hand, implements customer requirements and, on the other hand, does not increase the costs of further support and scaling, you need to know how Oracle Siebel CRM processes every event that a user or procedure initiates.
In general, the processing of events within each object goes through several stages:
In fact, Pre-Branch and Post-Branch are stubs, inside which developers have the opportunity to write their own handlers, that is, to lay down their event processing algorithm. The choice of the branch in which this algorithm is written depends on what the standard handler does. This article details two of the most commonly used events at the business component level: SetFieldValue (updating the field value) and WriteRecord (saving changes to the database).
Consider the Contact business component and its [Work Phone #] field. This is a common base field that the user can edit. Currently, the Immediate Post Change property for this field is set to 'Y':
What exactly does this property do, we will see later.
Next, consider such a script at the Contact business component level :
In fact, a handler is written on the Pre-Branch 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 won’t get to calling the standard handler.
It was before entering a new value:
Entering a new value:
After switching to another field: The
following happened:
Now consider the same situation, just transfer this script to the Post-Branch of the SetFieldValue event:
We repeat all the same actions and see a slightly different result:
Firstly, a 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 access the business component field on the Pre-Branch of the SetFieldValue event, the system will return the current value of the field that was there before the new value was entered. On the other hand, if you access the business component field on the Post-Branch of the SetFieldValue event, the system will return the value entered by the user.
All of the above principles work if the handlers for Post-Branch and Pre-Branch are launched through the Run-Time Events mechanism, and not through scripts.
To demonstrate this, consider this simple rule of validation (Administration - Data Validation):
Since 1 is never 0, each time the system accesses this rule, the user receives an error message, and the system stops further processing of the event that was triggered at that moment . Data Validation Manager is a separate big 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 needs to 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 component, if the [Email Address] field is updated. It is important to pay attention to Conditional Expression. Within its framework, the system should 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 respond to changes in the mailing address of an individual.
Initially, Email is filled with the value siebel@oracle.com:
Enter a new value, the length of which is less than 3 characters:
After moving to another field:
The system did not display any errors. The value remains the same. So the condition Len ([Email Address]) <3 did not pass. That is, the system at that moment was reading the old value in the [Email Address] field, which was equal to siebel@oracle.com, saw that the length of this value was more than 3, and did not start the handler. No error occurred, and the business component field was updated successfully.
If we now enter the old value in this field:
and switch 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 anyone knows how to get rid of the first in this case, write in the comments.If you understand the principle of the standard handler for the SetFieldValue event, the result will be quite logical.
Now you can make a small change to the considered Event:
In this case, the handler is bound to the Post-Branch of the SetFieldValue event. 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 siebel@oracle.com in the “Email” text box:
But if you try to enter a value of less than 3 characters, the following will happen:
The user will see an error message, but the value will remain in the business component field. An error message was displayed because Conditional Expression checked the length of the newly entered value. But, since the error occurred at the time of Post-Branch, that is, after the work of the standard handler, the entered value remained in place.
If the standard SetFieldValue event handler actually drops 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 in the corresponding tables is updated, which then other users of the system will be able to 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, the changes are sent to the database immediately for all fields.
If the developer writes his own handler and binds it to the Write-Record event Pre-Branch, then the system will perform all the actions before writing data to the database, otherwise, it will already be written to the database. 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 processor and the data in the database will be updated.
Knowing this fact, you can more competently implement business logic. For example, on the Pre-Branch, you need to hang up various data validation procedures to ensure that the "curve" information does not get into the database. You can attach notification procedures to the Post-Branch. For example, configure sending an Email-message when the application moves to a particular stage.
The property of the Immediate Post Change field, if it is equal to "Y", tells the system that the SetFieldValue event for the corresponding field needs to be triggered at the moment when the user made the changes and tries to move the cursor to another place. If it is not set, and for most fields it is, then the SetFieldValue event occurs as part of the WriteRecord event processing. 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 launches SetFieldValue, and only then WriteRecord is launched.
Given how Oracle Siebel CRM handles events, I recommend that you run data validation on the Pre-Branch WriteRecord event. In this case, when the user tries to save the 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.
Checking the values of each field will require a script, since the Run-Time Event does not have access to the new value when it is on the Pre-Branch of the SetFieldValue event.
All the principles described above apply not only when the user makes changes through the interface, but also when the EAI integration is working or just a script launches the SetFieldValue method directly. For example: bcContact.SetFieldValue (“Email Address”, “rrr@kk.ru”).
When designing a system, it is important to understand well how it will respond 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 exactly the architecture that, on the one hand, implements customer requirements and, on the other hand, does not increase the costs of further support and scaling, you need to know how Oracle Siebel CRM processes every event that a user or procedure initiates.
In general, the processing of events within each object goes through several stages:
- Pre-branch
- Standard handler
- Post-branch
In fact, Pre-Branch and Post-Branch are stubs, inside which developers have the opportunity to write their own handlers, that is, to lay down their event processing algorithm. The choice of the branch in which this algorithm is written depends on what the standard handler does. This article details two of the most commonly used events at the business component level: SetFieldValue (updating the field value) and WriteRecord (saving changes to the database).
SetFieldValue - script
Consider the Contact business component and its [Work Phone #] field. This is a common base field that the user can edit. Currently, the Immediate Post Change property for this field is set to 'Y':
What exactly does this property do, we will see later.
Next, consider such a script at the Contact business component level :
function BusComp_PreSetFieldValue (FieldName, FieldValue)
{
if (FieldName == "Work Phone #")
{
TheApplication().RaiseErrorText("Телефон: " + this.GetFieldValue("Work Phone #"));
}
return (ContinueOperation);
}
In fact, a handler is written on the Pre-Branch 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 won’t get to calling the standard handler.
It was before entering a new value:
Entering a new value:
After switching to another field: The
following happened:
 | At the initial stage, at all three levels the value was the same (adjusted for formatting, which is determined by the type of the DTYPE_PHONE field). |
 | After that, the user entered a new value in the text box "Work #" at the applet level. At this point, at the business component level and at the table level, the value has not changed. |
 | After the user switched focus from the “Work #” text box, the applet raised the SetFieldValue event at the business component level. At this point, the system saw that there was a script within the BusComp_PreSetFieldValue function, and began to execute it. 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 finishes processing the event, respectively, to the standard handler and the system did not reach the Post-Branch branch. As a result, the old phone value is displayed in the error text, and at the applet level the new value is also not saved. |
Now consider the same situation, just transfer this script to the Post-Branch of the SetFieldValue event:
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:
Firstly, a 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 has reached the execution of 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 that at the table level, nothing has changed at this point. You can verify this by executing a simple query to the database. |
From the above example, we can conclude: if you access the business component field on the Pre-Branch of the SetFieldValue event, the system will return the current value of the field that was there before the new value was entered. On the other hand, if you access the business component field on the Post-Branch of the SetFieldValue event, the system will return the value entered by the user.
SetFieldValue - Run-Time Event
All of the above principles work if the handlers for Post-Branch and Pre-Branch are launched through the Run-Time Events mechanism, and not through scripts.
To demonstrate this, consider this simple rule of validation (Administration - Data Validation):
Since 1 is never 0, each time the system accesses this rule, the user receives an error message, and the system stops further processing of the event that was triggered at that moment . Data Validation Manager is a separate big 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 | Bus service |
| 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 needs to 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 component, if the [Email Address] field is updated. It is important to pay attention to Conditional Expression. Within its framework, the system should 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 respond to changes in the mailing address of an individual.
Initially, Email is filled with the value siebel@oracle.com:
Enter a new value, the length of which is less than 3 characters:
After moving to another field:
The system did not display any errors. The value remains the same. So the condition Len ([Email Address]) <3 did not pass. That is, the system at that moment was reading the old value in the [Email Address] field, which was equal to siebel@oracle.com, saw that the length of this value was more than 3, and did not start the handler. No error occurred, and the business component field was updated successfully.
If we now enter the old value in this field:
and switch 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 anyone knows how to get rid of the first in this case, write in the comments.If you understand the principle of the standard handler for the SetFieldValue event, the result will be quite logical.
Now you can make a small change to the considered Event:
In this case, the handler is bound to the Post-Branch of the SetFieldValue event. 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 siebel@oracle.com in the “Email” text box:
But if you try to enter a value of less than 3 characters, the following will happen:
The user will see an error message, but the value will remain in the business component field. An error message was displayed because Conditional Expression checked the length of the newly entered value. But, since the error occurred at the time of Post-Branch, that is, after the work of the standard handler, the entered value remained in place.
Writerecord
If the standard SetFieldValue event handler actually drops 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 in the corresponding tables is updated, which then other users of the system will be able to 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, the changes are sent to the database immediately for all fields.
If the developer writes his own handler and binds it to the Write-Record event Pre-Branch, then the system will perform all the actions before writing data to the database, otherwise, it will already be written to the database. 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 processor and the data in the database will be updated.
Knowing this fact, you can more competently implement business logic. For example, on the Pre-Branch, you need to hang up various data validation procedures to ensure that the "curve" information does not get into the database. You can attach notification procedures to the Post-Branch. For example, configure sending an Email-message when the application moves to a particular stage.
Immediate Post Change
The property of the Immediate Post Change field, if it is equal to "Y", tells the system that the SetFieldValue event for the corresponding field needs to be triggered at the moment when the user made the changes and tries to move the cursor to another place. If it is not set, and for most fields it is, then the SetFieldValue event occurs as part of the WriteRecord event processing. 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 launches SetFieldValue, and only then WriteRecord is launched.
conclusions
Given how Oracle Siebel CRM handles events, I recommend that you run data validation on the Pre-Branch WriteRecord event. In this case, when the user tries to save the 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.
Checking the values of each field will require a script, since the Run-Time Event does not have access to the new value when it is on the Pre-Branch of the SetFieldValue event.
All the principles described above apply not only when the user makes changes through the interface, but also when the EAI integration is working or just a script launches the SetFieldValue method directly. For example: bcContact.SetFieldValue (“Email Address”, “rrr@kk.ru”).