Page Comparison

...

Note: For every hookpoint key you call, you will have to provide the validation XML file with the same name as the hookpoint key. That means, if you want to invoke the workflow with the hookpoint key 'YOUR_HOOKPOINT_KEY', then there should be a validation XML for this call named <path_to_xml_files>/YOUR_HOOKPOINT_KEY.xml.

Validation XML structure

One of the basic validation XMLs could look like this:

<?xml version="1.0" encoding="UTF-8"?>
<soapcall>
  <request>
    <hookpointKey>SOAP_CREATE_PAYMENT</hookpointKey>
    <values>
      <value mandatory="true" type="c" key="CONTEXT" desc="Context object, mandatory in each request.">
        <values>
          <value mandatory="true" type="s" key="LANGUAGE" regexp="[A-Z]{2}" desc="Language code. EN, FR, DK, SE, etc. Used for displaying error messages." />
          <value mandatory="true" type="s" key="OPERATOR" regexp="[a-z]{2,10}" desc="Operator information." />
          <value type="s" key="BRAND_ID" desc="Id of the brand if applicable." />
        </values>
      </value>
      <value mandatory="true" type="c" key="ACCOUNT_PAYMENT" class="com.CDRator.billing.financial.AccountPayment" desc="The account payment to store.">
        <values>
          <value mandatory="true" type="l" key="AMOUNT" desc="Amount paid." />
          <value mandatory="true" type="d" key="PAYMENT_DATE" desc="Date of the payment." />
          <value mandatory="true" type="s" key="REFERENCE" desc="Payment reference." />
          <value type="b" key="IS_VALID" />
        </values>
      </value>
    </values>
  </request>
  <response>
    <values>
      <value type="s" key="PAYMENT_ID" />
    </values>
  </response>
</soapcall>

As you can see, it includes, the hookpoint key and the value structure definition as well as what values will be returned in the SOAP response document.

There are 6 possible data types that can describe the structure of the data.

c - ComplexValueDTO
s - StringValueDTO
b - BooleanValueDTO
d - DateValueDTO
f - DoubleValueDTO
l - LongValueDTO

All data types except the ComplexValueDTO are basic, atomic data types and are specified with the following tag:

<value mandatory="true|false" type="s|d|l|b|f" regexp="[pattern if any]" key="VALUE_KEY" desc="Provide a brief description."/>

The ComplexValueDTO must have class key that specifies what kind of object is passed to the request. It may also have a list of values, those are the object attributes and can be any kind of data type. Example tag structure:

<value mandatory="true|false" type="c" key="VALUE_KEY" class="fully qualified class name, e.g.: com.example.Dummy" desc="A brief description if any.">
    <values>
        <value mandatory="true|false" type="s|d|l|b|f|c" regexp="[pattern if any]" key="VALUE_KEY" desc="Provide a brief description."/>
        ...
        <value>...</value>
    </values>
</value>

Take a look at the ACCOUNT_PAYMENT object definition above to get the idea how the object validation is organized.

Note: If you will make validation for nested complex types, then those objects and their attributes will be validated recursively. This gives a lot of flexibility and freedom to your service layer, but if you need to make some kind of very specific validation, e.g.: you want to check if key A is set and has value only if key B equals to TRUE. This is a limitation of the framework and should be implemented in the workflow as this is more business logic related validation rather than data structure related.

After the validation XML file is created and being used by the framework, the validation utility will expect the workflow context to have the described data types. If any of the described keys will be missing or will fail to pass validation, then the framework will return the SOAP response with the corresponding error message.

The section which describes the message response (the response tag) tells the framework to look for the specified keys in the workflow context and return the corresponding values in the SOAP response message. This means that, when designing your workflows, make sure that those keys you have specified are present in the workflow context before the workflow execution has finished.