Versions Compared

Old Version 45

changes.mady.by.user Torben Jensen

Saved on

compared with

New Version Current

changes.mady.by.user Søren Duusgaard (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Include Page
Workflows SOAP API
Workflows SOAP API

Requirements to the Workflow

  1. Workflows started by the SOAP method should contain only inProcess activities and be completely executed by the Tomcat, since SOAP methods are synchronous and should return the result within relatively short period of time.
  2. The hash table which is returned as the result of the workflow execution must contain only values of type long, double, String, Date or Hashtable. 
    1. It is possible however to configure transformation of PersistentObjects to extract specific fields and add them to the response. This is for some reason configured in the Validation xml - see below.
  3. The hash table which is returned as the result of the workflow execution must contain the values with the following keys used in the ResponseDTO to identify the status of the SOAP call: STATUS, ERROR_LEVEL, ERROR_MESSAGE.
  4. In most of the cases SOAP calls are used as a part of direct user interaction so the response time should be fast, which means embedded inProcess workflow should be executed within the corresponding time frames.

...

Code Block
languagehtml/xml
<dependency>
  <groupId>com.cdrator.integration.soap</groupId>
  <artifactId>rator-soap-workflow</artifactId>
  <scope>runtime</scope>
</dependency>

Also, don't forget remember to include the following dependency to build the deployable WEB application WAR file:

...

Parameter key

Possible values

Description

Available from version

SOAP.MONITORING.ENABLE_RATOR_MONITORING_HANDLER

T/F

 

 

SOAP.MONITORING.ENABLE_XML_PERSISTENCY

T/F

 

 

MONITORING_HANDLER

T/F

 

 

SOAP.MONITORING.ENABLE_XML_PERSISTENCY

T/F

 

 

SOAP.MONITORING.OBJ_ID_KEY.<HookpointKeyName><Key name for Request XML Element whose value should be saved to the OBJECT_ID column of the SOAP_MONITORING table>

A generic request object value can be saved to the SOAP_MONITORING table into the new column called OBJECT_ID by configuring this parameter tree entry with the key name of the Element to be saved.

So, it is possible to save a different object_id values for different soap hookpoints by configuring parameter entries with corresponding key name.

Note that it is not possible to save ComplexValueDTO object values in this column OBJECT_ID. Only simple object type value can be saved. i.e the key name provided in the parameter tree entry must correspond to a request XML element of simple ValueDTO type (String/Boolean/Long/Date/Double) , not a ComplexValueDTO type.


2.16-SNAPSHOT

SOAP.VALIDATION.IS_ENABLED

Y/N

 

 

SOAP.VALIDATION.PATH_TO_XMLS

 

Any path on a HDD where the application is deployed

 

SOAP.VALIDATION.CACHE_ENABLED

Y/N

Sets if caching of validation XML files is enabled. If parameter is not present, caching is enabled

2.8

SOAP.WORKFLOW.AUTHENTICATION.ENABLED

Y/N

 

 

SOAP.WORKFLOW.AUTHENTICATION.HOOKPOINT_KEY

 

Authentication/Role management workflow hookpoint key

 

SOAP.WORKFLOW.AUTHENTICATION.ADAPTER

 

Optional class name to handle authentication process

 

BRAND.DEFAULT_ENABLED

Y/N

When enabled, workflows started by workflow SOAP will have brand in the context.
The default brand is based on the brand_key from the properties.txt file

2.14

If you set the parameter SOAP.MONITORING.ENABLE_RATOR_MONITORING_HANDLER to T, then the framework monitoring handler will try to store the log record in the SOAP_MONITORING table. If there is no such table, then you might use the following script to create one:

...

You may have noticed that the validation xml example above contains a response element. This is used to configure transformation of complex objects (lists and persistent objects) on the workflow context to simple value DTO's that can be added to the response.
The example below will transform an arraylist of productconfig objects to a response xml including the id and product code as string value elements. It also transform the product field of the product config to a child element containing the id and description for that product.

Code Block

<response>
 <values>
  <value type="c" key="PRODUCT_CONFIGS" list="true">
   <values>
    <value type="c" key="PRODUCT_CONFIG" class="com.CDRator.billing.product.ProductConfig">
     <values>
      <value type="s" key="ID"/>
      <value type="s" key="PRODUCT_CODE"/>
       <value type="c" key="PRODUCT" class="com.CDRator.billing.main.Product">
        <values>
         <value type="s" key="ID"/>
         <value type="s" key="DESCRIPTION"/>
        </values>
       </value>
     </values>
    </value>
   </values>
  </value>
 </values>
</response>

Wiki Markup{table-plus}{table-plus}