Oracle Siebel CRM Event Model (Part 2)
- Tutorial
This article will cover a case study of using the event model. In addition, the Workflow tool will be introduced, which allows you to implement various event handlers.
Task: the user enters data in the field "Work Phone" and moves the cursor to another place in the interface. At this point, the system should read the entered value, clear the characters and apply a predefined format. For example, the user enters “7999) 44-333-22”, leaves the field, and the value changes to “+7 (999) 443-33-22”.
Oracle Siebel CRM has a special DTYPE_PHONE data type that can automatically overlay a format on a text field, but it has a number of limitations. In this case, I am considering the option when the "Work Phone" field is a regular text field.
To solve this problem, you need to write your SetFieldValue event handler. Since it is required that it work when the focus changes from the [Work Phone #] field to another area of the screen, we should set the value “Y” in the Immediate Post Change property of this field.
The phone number will be handled by a handler made using Workflow, which in turn will be launched through the Run-Time Event.
To start, I will create a simple stub based on Workflow that will not do anything yet:
This is Interactive Workflow, and it will work with the Contact business object. Now, if this Workflow is called via the Run-Time Event on the (View) screen, which is based on the Contact business object, it will receive the entire context that the user worked with and all actions (updating records, deleting, creating, querying data) ) will occur on behalf of this user.
At this stage, Workflow itself will look like this:
The first version of the handler is ready, now you need to bind it to the SetFieldValue event. The question is, which branch should I attach it to: Pre-Branch or Post-Branch? Since we need access to the newly entered value, it is logical to bind it to the Post-Branch, that is, after the standard SetFieldValue event handler has worked.
First you need to create an Action Set (Administration - Run-Time Events -> Action Sets) with one action, the parameters of which must be filled as follows:
Then you can bind this handler to the corresponding event:
After clearing the Run-Time Events cache and activating Workflow, you can verify through logging that the stub fires at the right time for us.
The Workflow logging level is set for each activated version on the Administration - Business Process -> Workflow Deployment -> Active Workflow Process page:
It is best to set the 3rd level of logging at the time of debugging. Now you can see the launch fact on the Administration - Business Process -> Workflow Instance Monitor -> Process Instances page:
At this point, everything is ready to write the handler itself, which will read the phone number entered by the user, process it and update the business component field with a new one value.
As mentioned earlier, the created Workflow will receive the entire context with which the user worked, and will begin to act on his behalf. That is, you do not need to make any request for the Contact business component - in this case, you can immediately read the value of the field of interest to us.
To read data in Workflow, you need to declare a new Phone variable:
This will be an internal text variable.
I recommend doing the reading of the values of the fields of the business components within the Workflow framework as follows:
I highly recommend not using a step with the Siebel Operation type to read data from the fields of a business component.
If you now activate the new version of Workflow, set the 3rd level of logging for it and update the field, then the value of the work phone entered by the user appears in the Workflow log:
After the steps taken, the processor learned to read the necessary data at the right time. Now it makes sense to write an algorithm that will transform the received phone into the specified format. To do this, you can make a separate business service or a new Workflow. What kind of tool we use to implement this algorithm does not matter much now, so here I will make a small stub that will simply add “+” to the entered value.
To solve this problem, you will need to use the Workflow Utility business service, which was already used earlier. It is needed just to update the values of Workflow variables: read data from the fields of a business component or apply some kind of formula.
In this case, the Phone variable is updated with a value that is obtained from concatenating the current value of the variable and the “+” symbol.
[& Phone] - access to the Workflow variable.
After transforming the phone, the created Workflow needs to be explained how to write data back to the same field. For this, a step with the Siebel Operation type is used:
In this case, the Update operation on the Contact business component is needed. The field to be updated is [Work Phone #], and the value must be taken from the Phone variable.
You can check the intermediate result by first activating the new version of Workflow and setting the 3rd level of logging for the new version.
This is the error the user receives when updating a field with the value 1234567890:
The system “swears” at our attempt to write a too long value in the [Work Phone #] field. The value that is now in this field is: “++++++++++++++++++++++++++++++++ 1234567890”.
After that, the following list is displayed on the Workflow monitoring screen:
In fact, the system went into recursion, which, in general, is logical, since we again triggered the same event when processing the SetFieldValue event. So, you need to somehow prevent the system from calling this handler if it is executing this Workflow.
You can solve this problem using the Profile Attributes tool. In fact, profile attributes are a set of global variables that are stored in the current user session.
The general idea of fixing the problem can be described as follows: before updating the field, a flag is set in the Workflow that will signal to the system that no transformation of the phone needs to be started now, but after the update the flag is reset. In practice, the implementation will look like this:
Updating a profile attribute inside Workflow:
Checking the value of a profile attribute in Conditional Expression Run-Time Event:
After updating the cache and activating a new version of Workflow, you can see the following results.
Data entry:
Going to the next field:
If you look at the database, you will notice that this new value is already there. Hence the conclusion: the Workflow step with the Siebel Operation type, which updates the fields of the business component, raises not only the SetFieldValue event, but also the WriteRecord.
After the system has learned to read data and update them, you can begin to implement the transformation procedure. This material is beyond the scope of the event model, so it will not be considered here.
Understanding the event model can greatly simplify the life of both the architect designing the system and the developers who need to implement everything as quickly and efficiently as possible. The proposed solution to the problem is far from ideal and is used here only to demonstrate the capabilities of the system.
Task: the user enters data in the field "Work Phone" and moves the cursor to another place in the interface. At this point, the system should read the entered value, clear the characters and apply a predefined format. For example, the user enters “7999) 44-333-22”, leaves the field, and the value changes to “+7 (999) 443-33-22”.
Oracle Siebel CRM has a special DTYPE_PHONE data type that can automatically overlay a format on a text field, but it has a number of limitations. In this case, I am considering the option when the "Work Phone" field is a regular text field.
Immediate Post Change
To solve this problem, you need to write your SetFieldValue event handler. Since it is required that it work when the focus changes from the [Work Phone #] field to another area of the screen, we should set the value “Y” in the Immediate Post Change property of this field.
Run-Time Event and Workflow
The phone number will be handled by a handler made using Workflow, which in turn will be launched through the Run-Time Event.
To start, I will create a simple stub based on Workflow that will not do anything yet:
This is Interactive Workflow, and it will work with the Contact business object. Now, if this Workflow is called via the Run-Time Event on the (View) screen, which is based on the Contact business object, it will receive the entire context that the user worked with and all actions (updating records, deleting, creating, querying data) ) will occur on behalf of this user.
At this stage, Workflow itself will look like this:
The first version of the handler is ready, now you need to bind it to the SetFieldValue event. The question is, which branch should I attach it to: Pre-Branch or Post-Branch? Since we need access to the newly entered value, it is logical to bind it to the Post-Branch, that is, after the standard SetFieldValue event handler has worked.
First you need to create an Action Set (Administration - Run-Time Events -> Action Sets) with one action, the parameters of which must be filled as follows:
| Action type | Bus service |
| Business service name | Workflow process manager |
| Business service method | Runprocess |
| Business service context | “ProcessName”, “SBL Phone Transformation Process” |
Then you can bind this handler to the corresponding event:
After clearing the Run-Time Events cache and activating Workflow, you can verify through logging that the stub fires at the right time for us.
The Workflow logging level is set for each activated version on the Administration - Business Process -> Workflow Deployment -> Active Workflow Process page:
It is best to set the 3rd level of logging at the time of debugging. Now you can see the launch fact on the Administration - Business Process -> Workflow Instance Monitor -> Process Instances page:
At this point, everything is ready to write the handler itself, which will read the phone number entered by the user, process it and update the business component field with a new one value.
Reading data
As mentioned earlier, the created Workflow will receive the entire context with which the user worked, and will begin to act on his behalf. That is, you do not need to make any request for the Contact business component - in this case, you can immediately read the value of the field of interest to us.
To read data in Workflow, you need to declare a new Phone variable:
This will be an internal text variable.
I recommend doing the reading of the values of the fields of the business components within the Workflow framework as follows:
- Create a step with the Bussiness Service type
- Fill in the property of this step:
- Name: Read Phone
- Business Service Name: Workflow Utilities
- Business Service Method: Echo
- For each field whose value you want to read, on the Output Arguments tab, create a record with the following properties:
- Property Name: Phone (name of the Workflow variable to read data into)
- Type: Business Component
- Business Component Name: Contact (name of the business component from which data will be taken)
- Business Component Field: Work Phone # (field name of the business component from which data will be taken)
I highly recommend not using a step with the Siebel Operation type to read data from the fields of a business component.
If you now activate the new version of Workflow, set the 3rd level of logging for it and update the field, then the value of the work phone entered by the user appears in the Workflow log:
Stub for transforming the phone
After the steps taken, the processor learned to read the necessary data at the right time. Now it makes sense to write an algorithm that will transform the received phone into the specified format. To do this, you can make a separate business service or a new Workflow. What kind of tool we use to implement this algorithm does not matter much now, so here I will make a small stub that will simply add “+” to the entered value.
To solve this problem, you will need to use the Workflow Utility business service, which was already used earlier. It is needed just to update the values of Workflow variables: read data from the fields of a business component or apply some kind of formula.
In this case, the Phone variable is updated with a value that is obtained from concatenating the current value of the variable and the “+” symbol.
[& Phone] - access to the Workflow variable.
Field update
After transforming the phone, the created Workflow needs to be explained how to write data back to the same field. For this, a step with the Siebel Operation type is used:
In this case, the Update operation on the Contact business component is needed. The field to be updated is [Work Phone #], and the value must be taken from the Phone variable.
You can check the intermediate result by first activating the new version of Workflow and setting the 3rd level of logging for the new version.
This is the error the user receives when updating a field with the value 1234567890:
The system “swears” at our attempt to write a too long value in the [Work Phone #] field. The value that is now in this field is: “++++++++++++++++++++++++++++++++ 1234567890”.
After that, the following list is displayed on the Workflow monitoring screen:
In fact, the system went into recursion, which, in general, is logical, since we again triggered the same event when processing the SetFieldValue event. So, you need to somehow prevent the system from calling this handler if it is executing this Workflow.
Profile Attributes
You can solve this problem using the Profile Attributes tool. In fact, profile attributes are a set of global variables that are stored in the current user session.
The general idea of fixing the problem can be described as follows: before updating the field, a flag is set in the Workflow that will signal to the system that no transformation of the phone needs to be started now, but after the update the flag is reset. In practice, the implementation will look like this:
- Prior to completing the Workflow step, in which the [Work Phone #] field is updated, a profile attribute is declared, for example, SBLNoTransformContactWorkPhone, and it is assigned the value “Y”.
- As part of the Run-Time Event, the system checks for the presence of this attribute and its value. If it exists and its value is “Y”, then no handler needs to be launched.
- After completing the Workflow step in which the [Work Phone #] field is updated, the same profile attribute is declared with the value “N”.
Updating a profile attribute inside Workflow:
Checking the value of a profile attribute in Conditional Expression Run-Time Event:
After updating the cache and activating a new version of Workflow, you can see the following results.
Data entry:
Going to the next field:
If you look at the database, you will notice that this new value is already there. Hence the conclusion: the Workflow step with the Siebel Operation type, which updates the fields of the business component, raises not only the SetFieldValue event, but also the WriteRecord.
After the system has learned to read data and update them, you can begin to implement the transformation procedure. This material is beyond the scope of the event model, so it will not be considered here.
conclusions
Understanding the event model can greatly simplify the life of both the architect designing the system and the developers who need to implement everything as quickly and efficiently as possible. The proposed solution to the problem is far from ideal and is used here only to demonstrate the capabilities of the system.