10 Configuring Dynamic and Static Event Templates for Return Parameters

This chapter describes how to create static and dynamic event templates for parameters returned from an network element (NE) as the result of an Oracle Communications ASAP work order.

About Static and Dynamic Event Templates for Return Parameters

Return parameters such as work order properties, information parameters, global work order parameters and service action return parameters can be returned on an ASAP Event. The details returned are controlled by template entries. These are configured using the eventTemplate object. The serviceAction and eventType attributes are used to identify the template. The returnDataSet object indicates which parameter names to retrieve. For more information refer to the descriptions of the tbl_event_dataset and tbl_event_template tables in the ASAP Developer's Guide.

Event templates can be configured statically or dynamically. Dynamic event templates are configured within work order properties sent to ASAP. Static event templates are configured within a cartridge. Dynamic event templates have precedence over static ones. Therefore, if there is any work order with a dynamic event template that matches an ASAP event related to that work order, no static event template will be checked.

For information about configuring dynamic event templates, see "Configuring a Dynamic Events Template". For information about creating a static event template, see Oracle Communications Design Studio for Activation Help.

ASAP searches for any configured event template when any one of the following events occurs:

Order Startup Event
Order Complete Event
Order Timeout Event
Order Fail Event

Note:

If work order event is not an Order Fail Event, ignore the service action specified in the Service Action field.

For an Order Startup event:

ASAP searches for an event template with the event type Order Startup Event and that has the same parameter name and value as the work order.
If the search returns nothing, ASAP searches for an event template that has the event type Order Startup Event.
If the search returns nothing, no event template is configured.

For an Order Complete event:

ASAP searches for an event template with the event type Order Complete Event and that has the parameter name and value as the work order.
If the search returns nothing, ASAP searches for an event template that has the event type Order Complete Event.
If the search returns nothing, no event template is configured.

For an Order Timeout event:

ASAP searches for an event template with the event type Order Timeout Event and that has same parameter name and value as the work order.
If the search returns nothing, ASAP searches for an event template that has the event type Order Timeout Event.
If the search returns nothing, no event template is configured.

For an Order Fail event:

ASAP searches for an event template with the event type Order Fail Event, has the service action specified in the Service Action field, and that has the same parameter name and value as the work order.
If the search returns nothing, ASAP searches for an event template that has the event type Order Fail Event, has the service and the same parameter name and value as the work order.
If the search returns nothing, ASAP searches for an event template that has the event type Order Fail Event and has the service action specified in the Service Action field.
If the search returns nothing, ASAP searches for an event template that has the event type Order Fail Event.
If the search returns nothing, no event template is configured.

Configuring a Dynamic Events Template

The extended work order property (or parameter) should be in the following format:

return_<event_template_name>%<event_type>%[service_action]

In this syntax, <...> means mandatory parameter, [...] means optional parameter; % is a separator.

Example:

return_ETEMP1%CompleteEvent%Service Action_1

Here,

ETEMP1 is the event template name.
CompleteEvent is the work order event type.
Service Action_1 is the service action name.

An extended work order parameter in the format above is passed from the work order as an extended work order property. The value of that parameter, even if specified, is ignored.

return_dataset_<event_template_name>%<parameter_type>%[service_action]%<parameter_name>"

In this syntax, <...> means mandatory parameter, [...] means optional parameter; % is separator.

Example:

return_dataset_ETEMP1%infoParam%Service Action_1%MCLI

Here,

ETEMP1 is the event template name.
infoParam is the parameter type.
Service Action_1 is the service action name (Service Action name)
MCLI is the name of the parameter.

The parameter type has to be one of the following event parameter types:

infoParam
orderParameter
serviceValue
extendedWoProperty

Example (xml) 1:

<createOrderByValueRequest…..
……
….
…

<mslv-sa:extendedWoProperties>

<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_ETEMP1%orderStartupEvent</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP1%extendedWoProperty%apiClientId</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP1%extendedWoProperty%XYZ</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>XYZ</mslv-sa:name>
<mslv-sa:value>12349</mslv-sa:value>
</mslv-sa:extendedWoProperty>

</mslv-sa:extendedWoProperties>

</orderValue>

</createOrderByValueRequest>

Example (xml) 2:

<createOrderByValueRequest…..
……
….
…

<mslv-sa:extendedWoProperties>

<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_ETEMP1%orderStartupEvent</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP1%extendedWoProperty%apiClientId</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP1%extendedWoProperty%XYZ</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>XYZ</mslv-sa:name>
<mslv-sa:value>12349</mslv-sa:value>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_ETEMP2%orderCompleteEvent</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%infoParam%INFOP_N1</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%orderParameter%TESTP2</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%serviceValue%Service Action_TELNET%XML_csdl_P1</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>

</mslv-sa:extendedWoProperties>

</orderValue>

</createOrderByValueRequest>

Example (xml) 3:

<createOrderByValueRequest…..
……
….
…

<mslv-sa:extendedWoProperties>

<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_ETEMP1%orderStartupEvent</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP1%extendedWoProperty%apiClientId</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP1%extendedWoProperty%XYZ</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>XYZ</mslv-sa:name>
<mslv-sa:value>12349</mslv-sa:value>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_ETEMP2%orderCompleteEvent</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%infoParam%INFOP_N1</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%orderParameter%TESTP2</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%serviceValue%Service Action_TELNET%XML_csdl_P1</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%infoParam%INFOP_N2</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%infoParam%INFOP_A1_N1</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>
<mslv-sa:extendedWoProperty>
<mslv-sa:name>return_dataset_ETEMP2%infoParam%Service Action_TELNET_B%INFOP_B1_N1</mslv-sa:name>
<mslv-sa:value/>
</mslv-sa:extendedWoProperty>

</mslv-sa:extendedWoProperties>

</orderValue>

</createOrderByValueRequest>

JSRP (OSS/J) Work Order Event Information

Additional information is returned for work order complete and failure events processed through JSRP servers. Network information is provided for failed services indicating what the last communicated network was when the service failed.

Extended work order complete and failure events contain the tags failedServices and services. This extension is configurable through a work order user property in order to provide backward compatibility. The failed services and services tags also contain the event template service parameters and info parameters, which may be used to pass upstream parameters that are relevant to services within an order.

For complete details of schema elements, refer to the ASAP Online Reference.

After ASAP is installed, you can access the schema files in the ASAP_Home/xml/xsd directory.

Extended Work Order Complete and Failure Schemas

The work order complete event (CompleteEventType) schema type includes the extended tags - failedServices, and services:

The failed event (FailEventType) schema type is extended as shown to include the two new tags - failedServices, and services:

Figure 10-1 Work Order Complete Event Schema

The failed event (FailEventType) schema type is extended as shown to include the two new tags - failedServices, and services.

Figure 10-2 Work Order Failed Event Schema

FailedServicesType Schema Type

The failedServicesType tag contains information detailing a failed work order's services. A failed service has the new fields reason, neId, tech_type and softwareLoad. These fields give the reason the work order failed failure for the service specified by serviceKey, and identify the NE that a network action (for example, atomic action, atomic action) was executing when the failure occurred.

Services Schema Type

The ServicesType tag includes details on services for a work order, except those that failed. As shown, each service inside the ServicesType tag includes a tag serviceState, which contains the state of the service.

The information parameters (infoParams) and service parameters (serviceParameters) are shown within the related service (instead at the order level as with previous releases).

Controlling the Return of Enhanced Event Information with includeServiceActionDetail

The work order user property includeServiceActionDetail is used to control the inclusion of the work order complete (CompleteEvent) and failure (FailedEvent) types.

If includeServiceActionDetail is true, the failedServices and services information will be included in the work order complete and failure events. If includeServiceActionDetail is false or if includeServiceActionDetail does not exist (the default), then the extra information is not included in the work order complete and failure events.

For example:

<mslv-sa:extendedWoProperties>

<mslv-sa:extendedWoProperty>

<mslv-sa:name>includeServiceActionDetail</mslv-sa:name>
<mslv-sa:value>true</mslv-sa:value>

</mslv-sa:extendedWoProperty>

...
<\mslv-sa:extendedWoProperties>

JSRP Server Configuration Parameter INCLUDE_SERVICE_ACTION_DETAIL

The JSRP server configuration parameter INCLUDE_SERVICE_ACTION_DETAIL controls this feature in addition to the work order user property includeServiceActionDetail.

If the JSRP server configuration parameter is set to true, then the failedServices and services information will be included in every work order complete, failure, or timeout event. The work order user property will override the JSRP server configuration parameter. The JSRP server configuration parameter is defined in the deployment descriptor for JSRP in the deployed ASAP$env_id.ear file.

Additional Event Data

With augmented event data, the work order properties, infoparms, global work order parameters, and service action return parameters can be returned on an ASAP event.

This additional event data and the contents of the additional event data are controlled by template entries. The extra parameter information is sent from the SARM to the JSRP, eliminating the need for the JSRP to perform additional queries to the database. Additionally, the SRT is able to add XML event data to the JMS header properties.�

Refer to ASAP Developer Reference for schema and other information.

OSS/J Support by Schema Parameters

The ASAP JSRP supports the following:

The co:type and sa:primaryKey tags of the sa:serviceKey tag in work orders are OSS/J compliant - the name of the service is provided by the tag co:type and the service instance number is provided by the tag sa:primaryKey.
Soft failures (that is, exceptions) and rollback exceptions are provided on a per service (for example, Service Action) basis, in addition to the work order level and rollback exceptions.
You can specify the service sequence numbers for a work order. (Previous versions of ASAP number the services according to the order in which they are put inside a work order.)

Notes

Service and failed service information is only provided only for work order complete, failure and timeout events.
The enhancements to the events apply only to events processed through JSRP servers.
The network information is provided only for failed services that indicate the last network communicated with when the service failed.

Work Order Property includeServiceActionDetail

The work order user property includeServiceActionDetail controls the extension of the work order complete, failure, and timeout event types with the two extended tags.

If the value is true, the failedServices and services information are included in the work order complete, failure, and timeout events. If the value is false or such a property does not exist (the default), then this extra information is not included in the work order complete, failure, and timeout events.

JSRP Server Configuration Parameter USE_ORIGINAL_INSTANCE_NUMBER

When the value of USE_ORIGINAL_INSTANCE_NUMBER is set to true, the <co:type> tag should be populated with service detail. The USE_ORIGINAL_INSTANCE_NUMBER parameter can be found in the ejb-jar.xml file in ASAP$env_id.ear:srp.