The <dcm:object-create>, <dcm:object-delete>, and <dcm:object-modify> elements are associated with the objects-from-def deploy.ant.xml target. This target is independent of the import-from-def target. The <dcm:object-*> elements deal directly with objects in the target domain, as opposed to objects from a .zip export file.

These three elements may occur 0-N times within a <dcm:definition> element and are "executed" in order.

The simplest element to understand and to specify is the <dcm:object-delete> element, which simply deletes the specified object from the domain.

The <dcm:object-create> element creates (or overwrites) an object. The configuration of the new object is specified in the body of the <dcm:object-create> element:

• Plain old SOMA XML for that object
• Cloned from an existing object in the domain
• Cloned from an object in a .zip export file

Simply cloning an object isn't very useful so there is an extensive set of techniques for modifying the configuration of the cloned object prior to actually creating that object in the domain.

The <dcm:object-modify> element modifies an existing object in the domain. This element shares a great deal of code with <dcm:object-create> since both leverage the same techniques for specifying which parts of the object's configuration need to be changed (see the subsection on configuration-modifying elements).

In essence, <dcm:object-create> gets the configuration of the object either from inline XML or from an existing object in the domain or a .zip export file while <dcm:object-modify> gets the configuration of that object directly from the domain. Once DCM has the initial object configuration in hand then it modifies that configuration and stores it into the domain, thus either creating a new object or overwriting the existing object.

Note several aspects, which may not be initially apparent, are intended features of the design:

• Filtering based on the environment="..." and deviceid="..." attributes applies to any inline XML elements

• The in-order "execution" of these elements means that it is possible to have a common <dcm:object-create> followed by an environment-specific or device-specific <dcm:object-modify> affecting the newly-created object, for example.

• This entire mechanism was originally designed to dynamically create actions and rules, and to then modify policy objects to reference those new rules. It is not an abuse of this mechanism to do sophisticated (wild and crazy) things. Provided, of course, that the resulting configuration actually works. ;-)

<dcm:object-delete class="..." name="..."/>

Required Attributes:

class - name of the object's class (e.g. LogTarget or MultiProtocolGateway)

name - name of the object

<dcm:object-create>
  [ inline SOMA XML for object configuration - e.g. copied from .zip export.xml ]
</dcm:object-create>

or

<dcm:object-create class="..." existing-name="..." new-name="...">
  [ configuration-modifying elements ]
</dcm:object-create>

or

<dcm:object-create class="..." existing-name="..." new-name="..." export="...">
  [ configuration-modifying elements ]
</dcm:object-create>

Required Attributes:

class - name of class (e.g. Matching or WSProxy)
existing-name - name of existing object
newname - name for object being created
export - path to .zip export file

<dcm:object-modify class="..." name="...">
  [ configuration-modifying elements ]
</dcm:object-create>

Required Attributes:

class - name of class (e.g. Matching or WSProxy)
name - name of existing object

These elements specify changes to make to the configuration of the object being created or modified, prior to creating/overwriting that object in the domain.

Here is a brief synopsis of the possibilities:

<xxx> (inline bits of SOMA XML)

<dcm:vector-delete class="...">
<dcm:vector-insert-before class="...">
<dcm:vector-insert-after class="...">
<dcm:vector-replace class="...">

<dcm:vector-insert-before class="..." ANCHOR>
<dcm:vector-insert-after class="..." ANCHOR>
<dcm:vector-delete class="..." ANCHOR>
<dcm:vector-replace class="..." ANCHOR>

Inine XML is simple - these are just elements that you want to add or replace in the existing configuration. For example:

<mAdminState>disabled</mAdminState>

Note that you may have any combination of inline SOMA XML and <dcm:vector-*> elements within <dcm:object-create> or <dcm:object-modify>. Their order is unimportant as well since DCM will apply them in the correct order based on the schema for the target appliance.

The SOMA vector concept is critical to understand. A vector is simply an element that can occur more than once. For example, <mAdminState> is not a vector because it must occur exactly once in the object configuration. On the other hand, <Certificate> IS a vector within a valcred object because it may occur 0-N times.

The <dcm:vector-* class="..."> elements affect all that class of element in the object configuration. Delete and replace are intuitively obvious while insert before places all the new elements before any of the existing elements, and insert after places all the new elements following all the existing elements.

The <dcm:vector-* class="..." ANCHOR> elements allow you to deal with specific elements in a vector. An ANCHOR is defined by one or more of these attributes, all of which must match in order for the <dcm:vector-* ANCHOR> element to take effect. Anchored elements allow you to make changes inside a vector, anchored to other elements already present in the vecor. Also, as a side effect, anchored elements are conditional vector modifications because if a match is not found then that vector modification element has no effect.

Each attribute in an ANCHOR is simply the name of a subelement and its expected content. For example, given this object:

<CryptoValCred name="vector-test-base">
  <mAdminState>enabled</mAdminState>
  <Certificate>cert-01</Certificate>
  <Certificate>cert-02</Certificate>
  <Certificate>cert-03</Certificate>
  <CertValidationMode>legacy</CertValidationMode>
  <UseCRL>on</UseCRL>
  <RequireCRL>off</RequireCRL>
  <CRLDPHandling>ignore</CRLDPHandling>
  <InitialPolicySet>2.5.29.32.0</InitialPolicySet>
  <ExplicitPolicy>off</ExplicitPolicy>
</CryptoValCred>

<dcm:vector-delete class="Certificate" content="cert-02"> would delete the second certificate from the valcred, leaving the cert-01 and cert-03. Note that the attribute name 'content' is special. Here is a different example.
Given this object:

<WSStylePolicy name="AbcWebServiceProxy">
  <mAdminState>enabled</mAdminState>
  <DefStylesheetForSoap>store:///filter-reject-all.xsl</DefStylesheetForSoap>
  <DefStylesheetForXsl>store:///identity.xsl</DefStylesheetForXsl>
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_default_request-rule</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_default_response-rule</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_rule_0</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
</WSStylePolicy>

(This is an object from web service proxy 'AbcWebServiceProxy' and it defines default request and response rules plus a proxy-level request rule.)

This element would insert a new policy map (presumably for a newly created WSStylePolicyRule):

<dcm:vector-insert-before class="PolicyMaps" rule="AbcWebServiceProxy_rule_0">
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_rule_1</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
</dcm:vector-insert-before>

Since rule="AbcWebServiceProxy_rule_0" matches the final policy map in the beginning configuration, and since this is an insert-before operation, the new policy map for rule 1 will be inserted ahead of rule 0, like this:

<WSStylePolicy name="AbcWebServiceProxy">
  <mAdminState>enabled</mAdminState>
  <DefStylesheetForSoap>store:///filter-reject-all.xsl</DefStylesheetForSoap>
  <DefStylesheetForXsl>store:///identity.xsl</DefStylesheetForXsl>
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_default_request-rule</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_default_response-rule</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_rule_1</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
  <PolicyMaps>
    <WSDLComponentType>fragmentid</WSDLComponentType>
    <WSDLComponentValue/>
    <Match class="Matching">AbcWebServiceProxy_match_all</Match>
    <Rule class="WSStylePolicyRule">AbcWebServiceProxy_rule_0</Rule>
    <Subscription/>
    <WSDLFragmentID>http://www.datapower.com/fragment-id#dp.all()</WSDLFragmentID>
  </PolicyMaps>
</WSStylePolicy>

Anchored vector operations contain one or more attributes whose name is the same as the name of a simple element in the configuration, ignoring case. The content of the attribute must match the content of the simple element.

It is not considered an error for an anchor to not match any element within the object configuration.