Defining software services with templates

Composite templates

A composite template is associated with a specific domain. The published standard templates that it contains must be in that domain.

The standard templates that are members of a composite template dictate the sequence that they provisioned in.

Variables: A provider can satisfy prompt variables that are associated with the standard template using the connectors field. If a prompt variable is also specified as a connector variable, the prompting of that variable is automatically disabled, because it is satisfied through the connectors field.

The composite template can also take in an optional variable input file, the composite properties file. This file contains atCreate variable values that are associated with the member standard templates. It is an alternative to providing the atCreate values with the Run action. The atCreate variable names are in this format: <standard-template>.<atcreate-variable-name>. If the composite properties file includes any variables that are associated with standard templates that are not members of the composite, those variables are ignored. All other variable names are validated to ensure they are atCreate variables associated with the member template. No validation is done on the values that are associated with the atCreate variables.

The precedence of values for the provisioning workflow is as follows. Values that are earlier in the list override values that are later in the list.

1. Connector and prompt values.
2. Values in the composite properties file.

The precedence of values for the action workflow is as follows:

1. Prompt values.
2. wfVar values that are specified in the actions definition.
3. Values in the composite properties file.

The resource pools that are associated with the standard templates that are referenced by the composite template must exist in the same tenant as the composite template.

Software services instances: When you use the Run operation for a composite template, multiple catalog type registry instances are created, one parent and a child for each standard template in the sequence.

The composite resource pool prefix is applied to the parent software services instance only. The standard template resource pool prefix is applied to each child software services instance.

An instance count is updated for both the composite resource pool and for each of the standard template resource pools.

The parent software services instance contains an array of composite registry objects, and each child includes the parent registry instance object ID.

Once all of the child software services instances are provisioned, the parent software services instance moves to the provisioned state, and you can use the child software services instances, that is, you can perform actions against them. The deprovisioning action is allowed only against the parent instance. The deprovisioning sequence is the opposite of the provisioning sequence.

If any of the children fail provisioning, you can either:

• Deprovision the failed provisioning child along with any child instances that have already been provisioned. Any child in the being-initialized state will remain as is – no deprovision action is run against it.
• Restart the failed child instance. If the restart is successful, it resumes the provisioning of the remaining children instances.

Once you have deprovisioned the parent instance (by using the Perform deprovision action against it), you can delete the parent instance, which also deletes all of the child instances.

Template Versions: When a new version of a standard template that is included in a composite template is published, any composite template that includes the standard template as a member is archived. The user then has the option to either re-publish one or more of the affected composite templates or create a new version of them.

When a standard template that is a member of one or more composite templates is moved out of published state (with the Archive or Delete actions) and a new standard template is not provided simultaneously, all affected composite templates are put into missing_required_member state. The composite templates remain in that state until a version of the missing member is published. The new version must be a version of the original member that was included in the composite definition. Once the missing member template is in publish state, the composite template is put into archive state if only that member template was missing. Otherwise, the composite template remains in missing_required_member state until all of the member templates are present. From the archive state, the provider or user can chose to re-publish the archived composite templates if the content of the standard templates and the connector information is still valid. If the content of the standard templates and the connector information is no longer valid, the user can create a new version of the archived composite template. The user should delete the previous version if it is no longer needed.

When all versions of a member template are deleted and a new unrelated standard template is published, all affected composite templates are put into missing_required_member state. The composite templates remain in that state indefinitely because there are no versions of the missing member template, and so the requirement that the member must be a version of the original member of the composite definition cannot be satisfied. The user can either delete the composite template or create a new version of it.