Oracle Siebel CRM Event Model (Part 2)
This article will consider a training example of using the event model. In addition, a Workflow tool will be introduced that 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 out unnecessary 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".
In Oracle Siebel CRM there is a special data type DTYPE_PHONE, which can automatically impose a format on a text field, but it has a number of limitations. In this case, I am considering the option when the field “Work Phone” is a regular text field.
')
To solve the 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 must set the value “Y” in the Immediate Post Change property of this field.
The phone number is cleared by the handler made using Workflow, which in turn will be launched via the Run-Time Event.
First, I will create a simple Workflow-based stub, which for the time being will not do anything:
This is an Interactive Workflow, and it will work with the Contact business object. Now, if this Workflow is triggered via a Run-Time Event on the screen (View), which is based on the Contact business object, then it will receive the entire context with which the user worked and all actions (updating records, deleting, creating, querying data ) will occur on behalf of this user.
Workflow itself at this stage will look like this:
The first version of the handler is ready; now it needs to be bound to the SetFieldValue event. The question is which branch to bind 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 works.
First you need to create an Action Set (Administration - Run-Time Events -> Action Sets) with one action, the parameters of which should be filled in as follows:
Then you can bind this handler to the corresponding event:
After clearing the Run-Time Events cache and activating Workflow, it will be possible to verify through logging that the stub is triggered at the right moment 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 fact of the launch on the page Administration - Business Process -> Workflow Instance Monitor -> Process Instances:
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 value.
As mentioned earlier, the created Workflow will receive the entire context with which the user worked, and will act on his behalf. That is, you do not need to make any request on the Contact business component - in this case, you can immediately read the value of the field of interest.
To read data within Workflow, you need to declare a new variable Phone:
This will be an internal text variable.
Reading the values ​​of the business component fields within Workflow, I recommend doing as follows:
I do not recommend using the step with the Siebel Operation type to read data from the fields of business components.
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 that the user has entered appears in the Workflow journal:
After these steps, the handler learned how to read the right data at the right time. Now it makes sense to write an algorithm that will transform the resulting 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 now does not matter much, so here I will make a small stub, which will simply add “+” to the entered value.
To solve this problem, you need to use the Workflow Utility business service, which has already been used before. It is needed precisely in order 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 the value that is obtained from the concatenation of the current value of the variable and the “+” symbol.
[& Phone] - access to the Workflow variable.
After the transformation of the phone to the created Workflow, you need to explain how to write the data back to the same field. To do this, use the step with the type of Siebel Operation:
In this case, you need an Update operation on the Contact business component. 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 pre-activating the new version of Workflow and setting the 3rd level of logging for the new version.
This is the error a user receives when updating a field with the value 1234567890:
The system “swears” at our attempt to record a too long value in the [Work Phone #] field. The value that is now in this field is: “++++++++++++++++++++++++++++++ 1234567890”.
On the screen with the monitoring of Workflow, after this, the following list is displayed:
In fact, the system entered recursion, which, in general, is logical, since we, when processing the SetFieldValue event, again initiated the same event. So, you need to somehow prevent the system from calling this handler if it executes the given workflow.
You can solve this problem with 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 ​​eliminating the problem can be described as follows: before updating the field within Workflow, some flag is set, which will signal to the system that now no transformation of the phone needs to be started, and after updating the flag is reset. In practice, the implementation will be as follows:
Updating profile attribute within Workflow:
Checking the profile attribute value in the Conditional Expression Run-Time Event:
After updating the cache and activating the new version of Workflow, you can see the following results.
Data input:
Go to the next field:
If you look into the database, you can see that this new value is already there. Hence the conclusion: the Workflow step with the type of Siebel Operation, which updates the fields of the business components, causes not only the SetFieldValue event, but also WriteRecord.
After the system has learned to read the data and update it, you can begin the implementation of 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 significantly 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 of 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 out unnecessary 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".
In Oracle Siebel CRM there is a special data type DTYPE_PHONE, which can automatically impose a format on a text field, but it has a number of limitations. In this case, I am considering the option when the field “Work Phone” is a regular text field.
')
Immediate Post Change
To solve the 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 must set the value “Y” in the Immediate Post Change property of this field.
Run-Time Event and Workflow
The phone number is cleared by the handler made using Workflow, which in turn will be launched via the Run-Time Event.
First, I will create a simple Workflow-based stub, which for the time being will not do anything:
This is an Interactive Workflow, and it will work with the Contact business object. Now, if this Workflow is triggered via a Run-Time Event on the screen (View), which is based on the Contact business object, then it will receive the entire context with which the user worked and all actions (updating records, deleting, creating, querying data ) will occur on behalf of this user.
Workflow itself at this stage will look like this:
The first version of the handler is ready; now it needs to be bound to the SetFieldValue event. The question is which branch to bind 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 works.
First you need to create an Action Set (Administration - Run-Time Events -> Action Sets) with one action, the parameters of which should be filled in as follows:
| Action type | Busservice |
| 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, it will be possible to verify through logging that the stub is triggered at the right moment 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 fact of the launch on the page Administration - Business Process -> Workflow Instance Monitor -> Process Instances:
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 value.
Reading data
As mentioned earlier, the created Workflow will receive the entire context with which the user worked, and will act on his behalf. That is, you do not need to make any request on the Contact business component - in this case, you can immediately read the value of the field of interest.
To read data within Workflow, you need to declare a new variable Phone:
This will be an internal text variable.
Reading the values ​​of the business component fields within Workflow, I recommend doing as follows:
- Create a step with type Bussiness Service
- Fill this step property:
- Name: Read Phone
- Business Service Name: Workflow Utilities
- Business Service Method: Echo
- For each field whose value is to be read, on the Output Arguments tab, create an entry with the following properties:
- Property Name: Phone (the name of the Workflow variable to which data should be read)
- Type: Business Component
- Business Component Name: Contact (the name of the business component from which the data will be taken)
- Business Component Field: Work Phone # (the name of the field is the business components from which the data will be taken)
I do not recommend using the step with the Siebel Operation type to read data from the fields of business components.
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 that the user has entered appears in the Workflow journal:
Phone transformation plug
After these steps, the handler learned how to read the right data at the right time. Now it makes sense to write an algorithm that will transform the resulting 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 now does not matter much, so here I will make a small stub, which will simply add “+” to the entered value.
To solve this problem, you need to use the Workflow Utility business service, which has already been used before. It is needed precisely in order 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 the value that is obtained from the concatenation of the current value of the variable and the “+” symbol.
[& Phone] - access to the Workflow variable.
Field update
After the transformation of the phone to the created Workflow, you need to explain how to write the data back to the same field. To do this, use the step with the type of Siebel Operation:
In this case, you need an Update operation on the Contact business component. 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 pre-activating the new version of Workflow and setting the 3rd level of logging for the new version.
This is the error a user receives when updating a field with the value 1234567890:
The system “swears” at our attempt to record a too long value in the [Work Phone #] field. The value that is now in this field is: “++++++++++++++++++++++++++++++ 1234567890”.
On the screen with the monitoring of Workflow, after this, the following list is displayed:
In fact, the system entered recursion, which, in general, is logical, since we, when processing the SetFieldValue event, again initiated the same event. So, you need to somehow prevent the system from calling this handler if it executes the given workflow.
Profile Attributes
You can solve this problem with 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 ​​eliminating the problem can be described as follows: before updating the field within Workflow, some flag is set, which will signal to the system that now no transformation of the phone needs to be started, and after updating the flag is reset. In practice, the implementation will be as follows:
- Prior to the execution of 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 should be run.
- After performing the Workflow step, in which the [Work Phone #] field is updated, the same profile attribute is declared with the value “N”.
Updating profile attribute within Workflow:
Checking the profile attribute value in the Conditional Expression Run-Time Event:
After updating the cache and activating the new version of Workflow, you can see the following results.
Data input:
Go to the next field:
If you look into the database, you can see that this new value is already there. Hence the conclusion: the Workflow step with the type of Siebel Operation, which updates the fields of the business components, causes not only the SetFieldValue event, but also WriteRecord.
After the system has learned to read the data and update it, you can begin the implementation of the transformation procedure. This material is beyond the scope of the event model, so it will not be considered here.
findings
Understanding the event model can significantly 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 of the problem is far from ideal and is used here only to demonstrate the capabilities of the system.
Source: https://habr.com/ru/post/236679/
All Articles