Define a New CI Type

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>

important

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>