Implementation Guide › Implementation › Business Logic Scripting (Business Logic Expert) › Inside the Business Logic › Registration

Registration

Registration is the process whereby the Business Logic submits a request to the calculation engine for the set of Raw Data Events that are to become a part of the calculation.

The registration process can be handled in two ways; Using the Registration Wizard or manually using the dispatcher object within the Business Logic.

Using the Registration Wizard is a simple process of choosing from the available options. You have all of the same options available as when doing the registration manually, without the ability to use parameters. If you need to use parameters, you will have to perform the registration manually. The basic flow of the wizard requires you to first determine which type of registration you would like to perform, then set the resource types and events upon which registration should be performed, and finally which event handler will be used to process the collected events.

Once the registrations are completed, they will appear listed in the 'Registration' tab of the Metric. Note also that it is possible to have more than one registration statement for a Metric.

In effect the Registration wizard uses the same functionality as the Manual registration, and all these options are discussed in the following section.

When performed manually within the Business Logic, the registration of the formula is handled by the OnRegistration event handler. This must be implemented in the formula and triggered whenever a Registration Engine Event is triggered. The Registration Event is triggered once when the Contract is activated, then every time a relevant resource or Change Set becomes active. A change in the affected resource is said to be relevant if it affects the events which the Metric is meant to receive. For example, if registration is done by Contract Party (RegisterByContractParty), this means that all the events of the defined type whose resources are attached to the Metric's Contract Party are a part of the calculation. In such a case, every time a new resource is attached or detached to that contract party, the registration method will be triggered to notify the Engine of the change.

The registration methods are provided by the Dispatcher object which is passed to OnRegistration as an argument. The different methods provide various ways in which to define the filtering criteria based on the event type definition and any resource allocation criteria, such as, resources of a resource group, or Resources of a certain type.

Using the Contract Party and Service registration methods is highly recommended because it makes it easier to use the Business Logic as a module or template. When doing so, the relevant Contract Party and Service is taken from the associated Metric definition and when re-using the formula for different contracts and/or service components, the registration does not need to change.

Another popular registration method is RegisterByResourceGroup, which is handy for working with resources that are logically grouped but may not always be associated with Contract Parties or Services. The assignment of resources to the groups here can then be managed by the resource catalog (individually or via Change Sets) and could even be updated automatically by translation scripts.

In general, the registration method is determined during the design phase and is directly driven by the defined data model.

Note: In order to check whether the Dispatcher object has been correctly used, the OnRegistration function is also called during the syntax checking of the SLALOM. For this reason, one should not assume that the OnLoad was run before the OnRegistration function and one should not use some of the properties of the context object, such as, "TimeUnit", "IntervalLength", "IsPeriod", "CorrectionsApply", and "ExceptionsApply" in the OnRegistration event-handler.

The registration methods are also responsible for associating the events with a procedure that will be triggered according to the event's timestamp. The procedure defined can have any name, but will always have the eventDetails object as its parameter. The eventDetails object reflects the Raw Data Event received and holds all of the event details as data fields, as shown in the following registration:

Sub OnRegistration(dispatcher)
dispatcher.RegisterByContractPartyAndService "OnMemUseEvent", "MemUse", "Server"
'the parameters of the method are: <procedure name>, <Event Type>, <Resource Type>
End Sub

The above registration statement tells us that all Raw Data Events of the 'MemUse' event type, and associated with the 'Server' Resource Type, will be sent to the 'OnMemUseEvent' event handler in the Business Logic.

The following procedure will also have to be defined ahead in the Business Logic:

Sub OnMemUseEvent(eventDetails)
 If InTimeSlot And eventDetails("MemoryUsage")>MaxMemoryUse Then
       MaxMsmoryUse = eventDetails("MemoryUsage)"
     End If
End Sub

By referring to the eventDetails object and using the 'MemoryUsage' parameter, the statement extracts the value of the MemoryUsage field from the event which was passed into the function. These fields are the same ones defined in the event type, and the field names are case sensitive.