1.1.2 Elements involved in service template development

Service templates define the information necessary to automate operating procedures. The following figure shows the elements involved in service template development:

Figure 1‒2: Elements Involved in service template development

• Development environment

  The environment in which the service template is developed. You can also conduct debugging and operation testing in this environment, to validate the operation of the service templates you develop. Although you can develop service templates in an active environment, we recommend that you keep the development and active environments separate.

• Active environment

  The environment in which you can add and execute services based on service templates you have developed. The actual automation of operating procedures takes place in this environment.

• Plug-in

  The smallest unit of processing you can define when automating IT operations.

• Service template

  Defines the processing that automates the operating procedures in an IT system. A service template incorporates flows and steps.

• Development service template

  A service template that is being developed by a user. Service templates created by copying a release service template are also classified as development service templates. Development service templates are used in the development environment.

• Release service template

  When you release a development service template, it becomes a release service template.You cannot edit a release service template. The service templates provided by JP1/AO are also classified as release service templates. Release service templates are used in the active environment.

• Flow

  Defines the flow of the operating procedure you are automating.

• Step

  An element of a flow, each step executes a plug-in.

The following describes how property mapping takes place for service templates and plug-ins:

The following figure shows an example of property mapping.

Figure 1‒3: Mapping service template and plug-in component properties

• Property mapping

  A service template defines a generic operating procedure. For this reason, properties that store the input values required to execute the service, such as host names and resource limits, are defined when services are added from a service template. These are called service input properties. The execution results of a service are output to the JP1/AO user interface as the values of service output properties.

  In plug-ins, input properties that store the input values required for plug-in execution and output properties that store execution results are defined. You can enter values into plug-in input properties directly, or pass values to them by linking them to a service input property or variable.

  By linking a service output property to a plug-in output property, you can review the execution results of a plug-in in the JP1/AO user interface. Linking properties in this way and passing values between them is called property mapping.

  • Mapping service input properties and plug-in input properties

    In the example in Figure 1‒3: Mapping service template and plug-in component properties, Input property 1 of the service is mapped to Input property 1 of Plug-in A, and Input property 2 of the service is mapped to Input property 2 of Plug-in B. Mapping is not configured for Input property 2 of Plug-in A.

    • The value input to Input property 1 of the service is input to Input property 1 of Plug-in A.

    • The value input to Input property 2 of the service is input to Input property 2 of Plug-in B.

    • The unmapped Input property 2 of Plug-in A is assigned the value entered when the service template was created or edited.

  • Mapping service output properties and plug-in output properties

    In the example in Figure 1‒3: Mapping service template and plug-in component properties, Output property 2 of Plug-in A is mapped to Output property 2 of the service, and Output property 1 of Plug-in B is mapped to Output property 1 of the service.

    • The execution results of Plug-in A (command standard output and standard error output, and output properties) output as Output property 2 of Plug-in A are also output to Output property 2 of the service. The user can then review the execution results of Plug-in A in the JP1/AO user interface.

    • The execution results of Plug-in B (command standard output and standard error output, and output properties) output as Output property 1 of Plug-in B are also output to Output property 1 of the service. The user can then review the execution results of Plug-in B in the JP1/AO user interface.

  • Mapping variables to plug-in properties

    In Figure 1‒3: Mapping service template and plug-in component properties, Output property 1 of Plug-in A is mapped to Variable 1, and Variable 1 is mapped to Input property 1 of Plug-in B.

    Values output as Output property 1 of Plug-in A are stored in Variable 1 then input to Input property 1 of Plug-in B. This passes the execution results of Plug-in A to an input property of Plug-in B, allowing it to be used in the processing of Plug-in B.

To Page Top