SeeAlso: EDRAWiki

Summary: Extending your EDRA schema

Actually, the EDRA schema has some predefined custom configuration elements for targets, handlers and transports, but you can add your own configuration elements. To do that you will have to specify a new namespace for these elements, this is a design problem of the current schema, and you can't add new configuration elements with a null namespace.

An example:

You created a new handler, for example, a Checksum algorithm handler. This new handler requires some configuration settings, so you put these settings within the handler definition in the pipeline, and the pipeline looks like this:

<serviceInterfacePipelines>

		  <before>
		     <handler handlerName="ChecksumValidation">
		       [<ChecksumSettings/>] <!-- Some settings -->
		     </handler> 
		  </before>
	

</serviceInterfacePipelines>

Actually, this definition doesn't work because you need to declare the """checksumSettings""" element with a different namespace ( This checksumSettings corresponds to the "any" element in the schema), so the pipeline definition should look like this:

<serviceInterfacePipelines>

		  <before>
		     <handler handlerName="ChecksumValidation" xmlns:my="myNamespace"> <!-- I've added a new namespace -->
		       [<my:ChecksumSettings/>] <!-- Some settings --> <!-- I've used the new namespace -->
		     </handler> 
		  </before>
	

</serviceInterfacePipelines>

The """checksumSettings""" element matchs with the following definition within the schema:

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="skip" /> ( A different namespace is required because the "namespace=##other" attribute was specified ).

The attribute """namespace=##other""" can't be replaced or removed because the schema becomes ambiguous with this change, so if you don't want to use a different namespace, you will have to add your element schema to the existing EDRA schema. Using the existing example, you want to add the new handlerUsage element to pipeline, actually the schema looks like this:

<xs:complexType name="handlerUsage">

		  <xs:sequence>
		    <xs:choice maxOccurs="unbounded" minOccurs="0">
		      <xs:element name="categories" type="ra:categories" minOccurs="0" maxOccurs="1" />
		      <xs:element name="timeoutConfiguration" type="ra:TimeoutConfiguration" minOccurs="0" maxOccurs="1" />
		      <xs:element name="authzConfiguration" type="ra:AuthzConfiguration" minOccurs="0" maxOccurs="1" />
		      <xs:element name="eventType" type="xs:string" minOccurs="0" maxOccurs="1" />
		      <xs:element name="duplicateHandlerSettings" type="ra:DuplicateHandlingSettings" minOccurs="0"	maxOccurs="1" />
		      <xs:element name="signOption" type="ra:signOption" minOccurs="0" maxOccurs="1" />
		      <xs:element name="messageTransformationSettings" type="ra:MessageTransformationSettings" minOccurs="0" maxOccurs="1" />
		      <xs:element name="syntactValidationSettings" type="ra:SyntactValidationSettings" minOccurs="0" maxOccurs="1" />
		      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="skip" />
		    </xs:choice>
		  </xs:sequence>
		  <xs:attribute name="handlerName" type="xs:string" use="required" />
		  <xs:attribute name="correlation" type="xs:string" use="optional" />
	

</xs:complexType>

After the change, the new schema will look like this:

<xs:complexType name="handlerUsage">

		  <xs:sequence>
		    <xs:choice maxOccurs="unbounded" minOccurs="0">
		      <xs:element name="categories" type="ra:categories" minOccurs="0" maxOccurs="1" />
		      <xs:element name="timeoutConfiguration" type="ra:TimeoutConfiguration" minOccurs="0" maxOccurs="1" />
		      <xs:element name="authzConfiguration" type="ra:AuthzConfiguration" minOccurs="0" maxOccurs="1" />
		      <xs:element name="eventType" type="xs:string" minOccurs="0" maxOccurs="1" />
		      <xs:element name="duplicateHandlerSettings" type="ra:DuplicateHandlingSettings" minOccurs="0"	maxOccurs="1" />
		      <xs:element name="signOption" type="ra:signOption" minOccurs="0" maxOccurs="1" />
		      <xs:element name="messageTransformationSettings" type="ra:MessageTransformationSettings" minOccurs="0" maxOccurs="1" />
		      <xs:element name="syntactValidationSettings" type="ra:SyntactValidationSettings" minOccurs="0" maxOccurs="1" />
		      <xs:element name="ChecksumSettings" type="ChecksumSettings" minOccurs="0" maxOccurs="1" /> <!-- New element -->
		      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="skip" />
		    </xs:choice>
		  </xs:sequence>
		  <xs:attribute name="handlerName" type="xs:string" use="required" />
		  <xs:attribute name="correlation" type="xs:string" use="optional" />
	

</xs:complexType>

Some considerations about the processContent attribute of the any element

Actually, the "any" elements of the handlers, targets and transports have a "skip" value in their processContent attribute. The possible values of this attribute are:

skip: The item must consist of well-formed XML and is not validated by the schema.

lax: If the item has a uniquely determined declaration available, it must be valid with respect to that definition. Otherwise, the item is not validated.

strict: The item must be schema-valid based on the schema definition obtained from the namespace-qualified item name.

If you decided to use a """lax""" or """strict""" value, then you will have to modify the EDRA configuration classes to pass the new schema file. Actually, the configuration sections are validated against the existing schemas included in the code. You will find all the validation code in the Core project, specifically in the following files:

"""PipelineSectionHandler.cs""" : All the code used to validate the "pipelineDefinitions" configuration section
"""ConfigurationSectionHandler.cs""" : All the code used to validate the "ReferenceArchitectureSection" configuration section
"""FrameworkHelperSectionHandler.cs""" : All the code used to validate the "frameworkHelperSettings" configuration section
"""BusinessActionSectionHandler.cs""" : All the code used to validate the "BusinessActionsDefinition" configuration section