Define a new CI type
This topic covers how to define new Configuration Item (CI) types in Deploy.
You can define new configuration item (CI) types in Deploy. When you specify a new type, its base (a concrete Java class or another synthetic type), and its namespace, the new type will become available in Deploy. The new CI type can now be a part of deployment packages and created in the Repository browser. Each of the three categories of CIs (deployables, deployeds, and containers) can be defined this way.
You can specify the following information when defining a new type:
Information | Required | Description |
---|---|---|
type | Yes | The CI type name. |
extends | Yes | The parent CI type that this CI type inherits from. |
description | No | Describes the new CI. |
virtual | No | Indicates whether the CI is virtual (used to group together common properties) or not. Virtual CIs can not be used in a deployment package. |
deployable-type | No | The type of deployable CI type that this CI type deploys. This is only relevant for deployed CIs. |
container-type | No | The type of CI container that this CI type is deployed to. This is only relevant for deployed CIs. |
generate-deployable | No | The type of deployable CI to be generated. This property is specified as a nested element. This is only relevant for deployed CIs. |
You can specify properties for the CIs that you define. For information about specifying a property, refer to Customize an existing CI type.
Define a deployable CI
Usually, deployable CIs are generated by Deploy. This example defines a tomcat.DataSource
CI and lets Deploy generate the deployable (tomcat.DataSourceSpec
) for it:
<type type="tomcat.DataSource" extends="tomcat.JndiContextElement" deployable-type="jee.DataSourceSpec" description="DataSource installed to a Tomcat Virtual Host or the Common Context">
<generate-deployable type="tomcat.DataSourceSpec" extends="jee.DataSourceSpec"/>
<property name="driverClassName" description="The fully qualified Java class name of the JDBC driver to be used."/>
<property name="url" description="The connection URL to be passed to our JDBC driver to establish a connection."/>
</type>
You can also copy default values from the deployed type definition to the generated deployable type. Here is an example:
<type type="tomcat.DataSource" extends="tomcat.JndiContextElement" deployable-type="jee.DataSourceSpec" description="DataSource installed to a Tomcat Virtual Host or the Common Context">
<generate-deployable type="tomcat.DataSourceSpec" extends="jee.DataSourceSpec" copy-default-values="true"/>
<property name="driverClassName" description="The fully qualified Java class name of the JDBC driver to be used." default="{{DATASOURCE_DRIVER}}"/>
<property name="url" description="The connection URL to be passed to our JDBC driver to establish a connection." default="{{DATASOURCE_URL}}"/>
</type>
When you use generate-deployable
, properties that are hidden
or that are of kind ci
, list_of_ci
, or set_of_ci
will not be copied to the deployable.
The following example shows an example of defining a deployable manually:
<type type="acme.CustomWar" extends="jee.War">
<property name="startApplication" kind="boolean" required="true"/>
</type>
Define a container CI
This example shows how to define a new container CI:
<type type="tc.Server" extends="generic.Container">
<property name="home" default="/tmp/tomcat"/>
</type>
Define a deployed CI
This example shows how to define a new deployed CI:
<type type="tc.WarModule" extends="udm.BaseDeployedArtifact" deployable-type="jee.War" container-type="tc.Server">
<generate-deployable type="tc.War" extends="jee.War"/>
<property name="changeTicketNumber" required="true"/>
<property name="startWeight" default="1" hidden="true"/>
</type>
The tc.WarModule
CI (a deployed) is generated when a tc.War
(a deployable) is deployed to a tc.Server
(a container). The new CI inherits all properties from the udm.BaseDeployedArtifact
CI and adds the required property changeTicketNumber
. The startWeight
property is hidden from the user with a default value of 1.
Define an embedded CI
An embedded CI is a CI that is embedded within another CI. The following example shows how to define an embedded CI that represents a portlet contained in a WAR file. The tc.Portlet
embedded CI can be embedded in the tc.WarModule
deployed CI, also shown:
<type type="tc.Server" extends="udm.BaseContainer">
<property name="host" kind="ci" referenced-type="overthere.Host" as-containment="true" />
</type>
<type type="tc.WarModule" extends="udm.BaseDeployedArtifact" deployable-type="jee.War" container-type="tc.Server">
<property name="changeTicketNumber" required="true"/>
<property name="startWeight" default="1" hidden="true"/>
<property name="portlets" kind="set_of_ci" referenced-type="tc.Portlet" as-containment="true"/>
</type>
<type type="tc.War" extends="jee.War">
<property name="changeTicketNumber" required="true"/>
<property name="startWeight" default="1" hidden="true"/>
<property name="portlets" kind="set_of_ci" referenced-type="tc.PortletSpec" as-containment="true"/>
</type>
<type type="tc.Portlet" extends="udm.BaseEmbeddedDeployed" deployable-type="tc.PortletSpec" container-type="tc.WarModule">
<generate-deployable type="tc.PortletSpec" extends="udm.BaseEmbeddedDeployable" />
</type>
The tc.WarModule
has a portlets
property that contains a set of tc.Portlet
embedded CIs.
In a deployment package, a tc.War
CI and its tc.PortletSpec
CIs can be specified. When a deployment is configured, a tc.WarModule
deployed is generated, complete with all of its tc.Portlet
portlet deployeds.
Define as-containment
CI types
One of the properties that you can set for CI types is as-containment
. This models the CI as a parent/child containment instead of as a foreign key reference in the JCR tree, ensuring that when the parent CI is undeployed, the child CI will also be undeployed.
The following example shows the use of the as-containment
property. Type modifications are needed for foreignDestinationNames
and foreignConnectionFactoryNames
because properties of kind set_of_ci
are not copied to the deployable.
<type type="wls.ForeignJmsServer" extends="wls.Resource" deployable-type="wls.ForeignJmsServerSpec" description="Foreign JMS Server">
<generate-deployable type="wls.ForeignJmsServerSpec" extends="wls.ResourceSpec" description="Specification for a foreign JMS server"/>
<property name="foreignDestinationNames" kind="set_of_ci" referenced-type="wls.ForeignDestinationName" required="false" as-containment="true" description="Foreign_Destination_Name" />
<property name="foreignConnectionFactoryNames" kind="set_of_ci" referenced-type="wls.ForeignConnectionFactoryName" required="false" as-containment="true" description="Foreign_Connection_Factory_Name" />
</type>
<type-modification type="wls.ForeignJmsServerSpec">
<property name="foreignDestinationNames" kind="set_of_ci" referenced-type="wls.ForeignDestinationNameSpec" required="false" as-containment="true" description="Foreign_Destination_Name" />
<property name="foreignConnectionFactoryNames" kind="set_of_ci" referenced-type="wls.ForeignConnectionFactorySpec" required="false" as-containment="true" description="Foreign_Connection_Factory_Name" />
</type-modification>