Oracle Siebel CRM Event Model (Part 3)

Introduction

In previous articles ( part 1 , part 2 ) I looked at the features of starting and processing the main events of the business component: SetFieldValue and WriteRecord. Now I want to refer to the user interface and look at how the applet handles the click of a button.



On almost every applet, we see a set of standard buttons that allow you to perform basic operations, such as create, delete, query. In addition to these, there are often buttons that call more specific procedures: complex parameter calculation, verification and data generation, data request from an external system, etc.
')
The principle of operation of all buttons is the same, both standard and specific. In fact, each of them causes an InvokeMethod event on the applet, to which the method that is predefined on a specific button is passed as a parameter:

Event Processing Scheme

The event processing scheme is as follows:



1. The system checks if there is an event handler on the Pre-Branch branch of this event at the applet level. If this handler does not exist, or it exists and has worked without errors, then the system refers to the standard applet handler.

2. The standard applet handler looks to see if it can handle the called method. If it does not, or it can, and the handler has completed without errors, then the standard applet handler triggers the InvokeMethod event on the business component on which the applet is based.

3. The system again checks whether there is a handler on the Pre-Branch of this event for this business component. After that, control is transferred to the level of the standard business component handler.

4. The standard handler looks at the method that was passed along with the InvokeMethod event, and if he does not recognize it, the system will stop processing and display an error. If this method is familiar to the business component, then it will process it, and then the control will switch to the Post-Branch branch of the InvokeMethod event at the business component level.

5. If a handler is defined on this thread, then it will do its job. If there were no errors here, then the control will be transferred to the Post Branch of the InvokeMethod event at the applet level.

Access to a button click

Knowing this scheme, you can easily extend the functionality of any standard handlers and set your business logic, but most often developers define completely new methods that standard InvokeMethod event handlers do not know either on the applet or on the business component. Based on the scheme, it turns out that if the processing of such a method reaches the level of the business component, the user will receive an error.

In addition to this problem, there is another issue of accessing the InvokeMethod event call for a particular method. By default, Siebel, if it does not know the method defined on the button, then the button is not available for pressing.





There are several ways to solve this problem. One of the most common ways is a script at the applet level:

function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke) { if (MethodName == "TestMethod") { CanInvoke = "TRUE"; return (CancelOperation); } return (ContinueOperation); } 

This solution is quite flexible and allows you to write complex logic to determine access to this method, and, accordingly, to the press of a button. However, there are more elegant solutions. For example, it is possible to define a User Property at the level of the CanInvokeMethod applet: <Method Name>. The value of this property can be any logical expression written in the Siebel Query Language, including the use of the ParentFieldValue function to access the fields of the parent business component.

Standard handler error

As soon as the button becomes available for pressing, it is possible to write your own handler. However, as I mentioned earlier, we get an error that the standard InvokeMethod event handler returns at the business component level:



There are two approaches to how to avoid this error. The first is based on not allowing the system to reach the standard handler at the level of business components. This can be done by stopping the processing on the Pre-Branch applet or business components through a script:

 function BusComp_PreInvokeMethod (MethodName) { if (MethodName == "TestMethod") { // Do Something return (CancelOperation); } return (ContinueOperation); } 

Operator return (CancelOperation); stops all further processing.

The second approach is based on telling the standard handler that no errors should be output to this method. Here again there are two ways to do it. The first is related to the use of the User Property “Named Method n” at the applet level or at the business component level. I plan to consider using this property in the next article. Here we look at the easiest and most interesting way associated with the use of the EventMethod prefix in the method name.

The point is very simple: when you specify a method name for a button, if it is not standard, you need to start it with an EventMethod. When the standard InvokeMethod event handler on the business component receives such a method name, it simply does nothing, but transfers control further along the scheme. If in the example considered here the method name is changed to EventMethodTestMethod, we get the following picture:





The button is active, and clicking on it does not lead to errors. You can also notice the fact that I did not change the button activation logic in any way: there is no script, the CanInvokeMethod property activates strictly the TestMethod method. Thus, this is a solution to two problems at once.

Using this approach, we are changing the basic paradigm. Now everything that is not forbidden is allowed. So, after adding such a button, you need to think about how to restrict access to this button. For this, you can use the CanInvokeMethod already discussed above.

Important note: in order for the EventMethod trick to work correctly, it is necessary that the class of business components on which the applet is based be equal to either CSSBCBase or any one inherited from it. This means that for the class CSSBusComp, which by default is prescribed for each new business component, this solution will not work.

findings

1. When creating a new business component, always specify the class name CSSBCBase. It gives a lot of useful things, including the functionality related to EventMethod.

2. When creating buttons that automate system functionality, I recommend using EventMethod method for its activation and CanInvokeMethod for defining access rules in the name of the button. This will significantly help reduce the number of scripts and facilitate the development process.

3. Subject to the preceding paragraph, button handlers can be hung on any branch, both on Pre-Branch and Post-Branch. It is advisable to set the logic at the level of the applet.

4. Using the CanInvokeMethod property, you can limit access to standard applet methods: NewRecord, DeleteRecord, NewQuery, ExecuteQuery, using a predefined condition. However, when restricting access to the NewRecord method, you should not use the fields of the current entity. Most likely, there will be an appeal to the profile attributes via the GetProfileAttr () function or to the fields of the parent record via the ParentFieldValue () function.