Integrate > CA APM > Configure > CA Wily Plug-in Technical Information

CA Wily Plug-in Technical Information

Usage

CA Wily plug-in consists of two nodes, which in combination with WS plug-in make a complete solution for CA Wily BSM integration.

General Information

Library Name: caapm-plugin.dll / caapm-plugin.so

CA Wily SOAP Source Node

Node Type: source_node

Plug-in Index: 0

This node sends SOAP requests to the CA Wily WS interface and extracts the relevant information from responses. In order to extract the required piece of information, it relies on the fact that both input data (which is the SOAP message) and output data (which is the GenInt message) are actually tree structures and so it actually needs to transform one tree structure into another. This allows us to make it very generic and configurable and put all the extraction logic into the GenInt configuration file.

Parameter Name Parameter Type Default Value Required Description
Connection Control Parameters
base-url string   yes CA Wily endpoint
username string Empty string   In case authentication is required for CA Wily
password string Empty string   If not empty then use authentication against CA Wily.
proxy-host string Empty string   If not empty then use this proxy.
proxy-port unsigned string Empty string   Proxy port
Proxy-username string Empty string   If not empty then use proxy authentication.
proxy-password string Empty string   Proxy password
timeout long 0   Connection timeout in seconds. The default is 0 which means that request never times out.
client-request-file string   yes Path to the client request definitions file.
Execution Control Parameters
interval Unsigned long 60   The time (in seconds) to wait after one execution. The value of this parameter will be ignored in case single-run was specified.
max-interval-window Unsigned long 900   Controls the maximum time window between the current execution time and the last execution time. In case the window exceeds this value (e.g. due to HTTP connection errors) it is truncated (last execution time is updated).
single-run bool false   If the interval is set to true, the execution performs only once. In case of an error during script execution, it will be tried to re-run, until it succeeds once.
Output Message Control Parameters
integration-name string   yes Output message integration name
integration-type string   yes Output message integration name
message-per-root-node bool false   If the interval is set to true, then a new message will be created for every output root node (set as nodes-level-1) found in the request. If false then all the output information is stored in a single output message.
Transformation Control Parameters
service[-n] String   yes CA Wily WS service to call. In case more than one request needs to be processed, specify sequence numbers.
operation[-n] String   yes Specify the WS service operation to call. In case more than one request needs to be processed at once then also specify sequence numbers.
[operation[-n-]]nodes-level-[n] String   yes In the output tree structure (message) for every node in level n specify the XPath of the corresponding node in input tree structure.
[additional request parameter] String     In case a request has a parameter set in the requests file, then specify a parameter value.

client-requests-file parameter

This is a path to the client request definitions file. The file actually contains the (parametrized) SOAP requests.

Sample from definitions file:

</CAWilyClient>
  ...
  <MetricsDataService>
    <path>/introscope-web-services/services/MetricsDataService</path>
    <getMetricData>
      <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:met="http://metricsdata.webservicesimpl.server.introscope.wily.com">
        <soapenv:Header/>
        <soapenv:Body>
          <met:getMetricData soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
            <agentRegex xsi:type="xsd:string">.*?</agentRegex>
            <metricRegex xsi:type="xsd:string">${metric-regex}</metricRegex>
            <startTime xsi:type="xsd:dateTime">${start-time}</startTime>
            <endTime xsi:type="xsd:dateTime">${end-time}</endTime>
            <dataFrequency xsi:type="xsd:int">60</dataFrequency>
          </met:getMetricData>
        </soapenv:Body>
      </soapenv:Envelope>
    </getMetricData>
  </MetricsDataService>
  ...
</CAWilyClient>

 

This above code snippet contains the service name element (needs to be specified in the configuration – in this case MetricsDataService). Service name element contains the path element that tells which relative HTTP path to use to get to the CA Wily service. It also contains the name of the operation to call (in this case getMetricData). A WS service usually has many operations. Finally, an operation element contains a specific SOAP request message.

A request SOAP message can have additional parameters in the form of ${parameter_name}. In the above example, we can see three such parameters: ${metric-regex}, ${start-time} and ${end-time}. Each of the parameters need to be configured in the GenInt node configuration. If it is not specified in the configuration, it defaults to an empty string.

The example configuration that accompanies the above request looks like this:

source (metriccollector, " ${GenintBinDir}\genint-plugins \cawily-plugin.dll", 0)
{
	"integration-name" : "metric",
	"integration-type" : "METRIC",
	...
	"service" : "MetricsDataService",
	"operation" : "getMetricData",
	...
	"metric-regex" : ".*?",
	"start-time" : "@{LastExecutionTimeInMin}",
	"end-time" : "@{ExecutionTimeInMin}"
}
...

 

nodes-level-[n] parameter

This parameter controls the data extraction mechanism from the input SOAP message. It is in the following format:

nodes-level-[n]= [output message node name]=[XPath of the corresponding node in the input SOAP][, ...]

Root nodes are specified as nodes-level-1 parameter. Note that there can be more than one root node. Root nodes are the direct children of the output GenInt message. In case message-per-root-node configuration parameter is set to true, then a new message (with integration-name = [root node name]) will be created for every root node found in the input SOAP message.

XPath can be absolute or relative. The absolute XPath is used for output root nodes (specified as nodes-level-1) and starts with ‘/’. Relative root node starts with the parent node name in the input SOAP message and is used for all other output nodes (nodes-level-2, nodes-level-3...). For example, if nodes-level-1=/root/parent_node, then a valid child node XPath would be nodes-level-2=parent_node/child_node. Starting with the parent node name in relative XPath for a node in nodes-level-[n] also helps us identify which parent the XPath refers to, in case we have many nodes specified in nodes-level-[n-1].

CA Wily uses obsolete rpc/encoded SOAP communication where child elements are specified in the following format:

...
<parent_element href=”#id1” />
...
<multiRef id=”id1”>...</multiRef
...

XPath standard does not support these kind of references. Instead of using an XPath library, we needed to implement suitable custom XPath. In our custom implementation, we use @href to support this kind of parent-child link. For example, XPath would look like this:

.../parent_element/@href/...

In order to see nodes-level-[n] parameter in action, let us consider the example - calling ApmConfigService#getEMProperties WS operation:

"integration-name" : "em_topology",
"integration-type" : "TOPOLOGY",
"service" : "ApmConfigService",
"operation" : "getEMProperties",
"nodes-level-1" : "em=/Envelope/Body/getEMPropertiesResponse/getEMPropertiesReturn/@href",
"nodes-level-2" : "fqdn=multiRef/emHostName,ip_v4=multiRef/emIpAddress,name=multiRef/name"

An example input SOAP message looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
        <ns1:getEMPropertiesResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            xmlns:ns1="http://impl.webservices.model.apm.wily.com">
            <getEMPropertiesReturn href="#id0"/>
        </ns1:getEMPropertiesResponse>
        <multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:DEMProperties"
            xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
            xmlns:ns2="urn:com.wily.apm.model.webservices.common">
            <emHostName xsi:type="xsd:string">devcawily9.doitwise.lab</emHostName>
            <emIpAddress xsi:type="xsd:string">10.1.1.78</emIpAddress>
            <emLaunchTime xsi:type="xsd:long">1450698176342</emLaunchTime>
            <emPort xsi:type="xsd:string">5001</emPort>
            <emVersion xsi:type="xsd:string">9.5.3.0</emVersion>
            <name xsi:type="xsd:string">Introscope Enterprise Manager</name>
            <webServerSecurePort xsi:type="xsd:int">-1</webServerSecurePort>
            <webServerUnsecurePort xsi:type="xsd:int">8081</webServerUnsecurePort>
        </multiRef>
    </soapenv:Body>
</soapenv:Envelope>

The corresponding output GenInt message looks like this:

<message>
  <genint_meta>
    <integration_name>em_topology</integration_name>
    <integration_type>TOPOLOGY</integration_type>
  </genint_meta>
  <em>
    <fqdn><![CDATA[devcawily9.doitwise.lab]]></fqdn>
    <ip_v4><![CDATA[10.1.1.78]]></ip_v4>
    <name><![CDATA[Introscope Enterprise Manager]]></name>
  </em>
</message>

 

service[-n] and operation[-n] parameters

Service and operation parameters uniquely identify the WS call in the client-requests-file. In case we need to call more than one request per execution (in case of data aggregation or one request data is bound to another request data), we specify more than one service/operation parameters. The calls are executed in sequence. For example, to call BusSvcService# getAllBusinessServices, we specify the following configuration:

"service-1" : "BusSvcService",
"operation-1" : "getAllBusinessServices",
"operation-1-nodes-level-1" : "business_service=/Envelope/Body/.../getAllBusinessServicesReturn",
"operation-1-nodes-level-2" : "id=getAllBusinessServicesReturn/..., name=...",
"service-2" : "BusTransService",
"operation-2" : "getAllBusinessTrans",
"operation-2-nodes-level-1" : "business_transaction=/Envelope/Body/.../getAllBusinessTransReturn",
"operation-2-nodes-level-2" : "id=getAllBusinessTransReturn/...,business_transaction_name=...,..."

Service is shorthand for service-1, operation is shorthand for operation-1 and nodes-level-[n] is shorthand for operation-1-nodes-level-[n].

CA Wily Processing Node

Node Type: processing_node

Plugin Index: 1

This node performs the main business logic in CA Wily plug-in. It transforms the input GenInt message (which is the source node output) into output GenInt message (or messages) expected by WS plug-in. The output messages need to be in the format that WS plugin can understand. Topology output messages are consumed by WS plug-in node with index 1 while the metrics output messages are consumed by WS plugin node with index 0.

The differences between the transformations performed by source and processing nodes are:

  1. The source node transformation is only used to extract the data. It does not perform any additional job such as splitting the agent or metric name and taking the appropriate information. It does not perform any business logic. On the other side, the processing node performs all the business logic specific to CA Wily-BSM integration.
  2. The source node transformation is configurable and it is specified in the configuration file. On the other side, the processing node logic is static. It contains the CA Wily-BSM integration business logic and is not specified in the configuration file.

Currently there are four different transformations performed by the processing node. The type of transformation that is performed on a message is determined by the integration-name and integration-type of an input message. Each transformation is described below.

EM Topology Transformation

This transformation is performed if an input message has the following properties:

  • integration-name em_topology
  • integration-type TOPOLOGY

An input message contains the CA Wily Enterprise Manager instances. For every EM instance, the transformation creates a node CI, an ip_address CI and a relation between them. An example of the expected input message looks like the following xml:

<message>
  <genint_meta>
    <integration_name>em_topology</integration_name>
    <integration_type>TOPOLOGY</integration_type>
  </genint_meta>
  <em>
    <fqdn><![CDATA[devcawily9.doitwise.lab]]></fqdn>
    <ip_v4><![CDATA[10.1.1.78]]></ip_v4>
    <name><![CDATA[Introscope Enterprise Manager]]></name>
  </em>
  ...
</message>

The output message looks like the following xml (serialized by xmlout-plugin):

<message>
  <genint_meta>
    <integration_name>em_topology</integration_name>
    <integration_type>TOPOLOGY</integration_type>
  </genint_meta>
  <instance>
    <key><![CDATA[node:Introscope Enterprise Manager]]></key>
    <attributes>
      <ucmdb_data_externalid><![CDATA[Introscope Enterprise Manager]]></ucmdb_data_externalid>
      <ucmdb_primary_dns_name><![CDATA[devcawily9.doitwise.lab]]></ucmdb_primary_dns_name>
      <hpom_citype><![CDATA[node]]></hpom_citype>
      <hpom_discoTarget><![CDATA[BSM]]></hpom_discoTarget>
      <ucmdb_name><![CDATA[Introscope Enterprise Manager]]></ucmdb_name>
      <ucmdb_description><![CDATA[Created by CA Wily]]></ucmdb_description>
    </attributes>
  </instance>
  <instance>
    <key><![CDATA[10.1.1.78]]></key>
    <attributes>
      <ucmdb_user_label><![CDATA[10.1.1.78]]></ucmdb_user_label>
      <hpom_citype><![CDATA[ip_address]]></hpom_citype>
      <hpom_discoTarget><![CDATA[BSM]]></hpom_discoTarget>
      <ucmdb_name><![CDATA[10.1.1.78]]></ucmdb_name>
      <ucmdb_description><![CDATA[Created by CA Wily]]></ucmdb_description>
    </attributes>
  </instance>
  <relation>
    <parent><![CDATA[node:Introscope Enterprise Manager]]></parent>
    <generic>
      <containment><![CDATA[10.1.1.78]]></containment>
    </generic>
  </relation>
  ...
</message>

 

System Topology Transformation

This transformation is performed if an input message has the following properties:

  • integration-name system_topology
  • integration-type TOPOLOGY

An input message contains the CA Wily agents. For every agent the transformation creates a node CI, a running_software CI, an ip_address CI and a relation between node and ip_address. Note that a relation between node and running_software is not required since it is automatically created by BSM due to hpom_rootcontainer attribute of running_software instance. An example of the expected input message looks like this (serialized by xmlout-plugin):

<message>
  <genint_meta>
    <integration_name>system_topology</integration_name>
    <integration_type>TOPOLOGY</integration_type>
  </genint_meta>
  <agent>
    <agent_id><![CDATA[20]]></agent_id>
    <agent_name><![CDATA[PerfMonCollectorAgent.exe]]></agent_name>
    <process_name><![CDATA[.NET Process]]></process_name>
    <fqdn><![CDATA[devdynatrace6.doitwise.lab]]></fqdn>
    <host_name><![CDATA[devdynatrace6]]></host_name>
    <ip_v4><![CDATA[10.1.1.75]]></ip_v4>
  </agent>
  ...
</message>

 

The transformed output message looks like the following (serialized by xmlout-plugin):

<message>
  <genint_meta>
    <integration_name>system_topology</integration_name>
    <integration_type>TOPOLOGY</integration_type>
  </genint_meta>
  <instance>
    <key><![CDATA[node:20:devdynatrace6]]></key>
    <attributes>
      <ucmdb_data_externalid><![CDATA[devdynatrace6]]></ucmdb_data_externalid>
      <ucmdb_discovered_location><![CDATA[Default-First-Site-Name]]></ucmdb_discovered_location>
     <ucmdb_primary_dns_name><![CDATA[devdynatrace6.doitwise.lab]]></ucmdb_primary_dns_name>
      <hpom_citype><![CDATA[node]]></hpom_citype>
      <hpom_discoTarget><![CDATA[BSM]]></hpom_discoTarget>
      <ucmdb_name><![CDATA[devdynatrace6]]></ucmdb_name>
      <ucmdb_description><![CDATA[Created by CA Wily]]></ucmdb_description>
    </attributes>
  </instance>
  <instance>
    <key><![CDATA[software:20:PerfMonCollectorAgent.exe]]></key>
    <attributes>
      <ucmdb_data_externalid><![CDATA[PerfMonCollectorAgent.exe]]></ucmdb_data_externalid>
      <hpom_rootcontainer><![CDATA[node:20:devdynatrace6]]></hpom_rootcontainer>
      <hpom_citype><![CDATA[running_software]]></hpom_citype>
      <hpom_discoTarget><![CDATA[BSM]]></hpom_discoTarget>
      <ucmdb_name><![CDATA[PerfMonCollectorAgent.exe]]></ucmdb_name>
     <ucmdb_discovered_product_name><![CDATA[.NET Process]]></ucmdb_discovered_product_name>
      <ucmdb_description><![CDATA[Created by CA Wily]]></ucmdb_description>
    </attributes>
  </instance>
  <instance>
    <key><![CDATA[10.1.1.75]]></key>
    <attributes>
      <ucmdb_user_label><![CDATA[10.1.1.75]]></ucmdb_user_label>
      <hpom_citype><![CDATA[ip_address]]></hpom_citype>
      <hpom_discoTarget><![CDATA[BSM]]></hpom_discoTarget>
      <ucmdb_name><![CDATA[10.1.1.75]]></ucmdb_name>
      <ucmdb_description><![CDATA[Created by CA Wily]]></ucmdb_description>
    </attributes>
  </instance>
  <relation>
    <parent><![CDATA[node:20:devdynatrace6]]></parent>
    <generic>
      <containment><![CDATA[10.1.1.75]]></containment>
    </generic>
  </relation>
  ...
</message>

 

Transaction Topology Transformation

This transformation is performed if an input message has the following properties:

  • integration-name transaction_topology
  • integration-type TOPOLOGY

An input message contains the CA Wily business services as well as business transactions for those business services. A business service can have zero or many business transactions. For every business service - business transaction pair, the transformation creates a business_application CI, a business_transaction CI and a relation between them. If a business service does not have a business transaction, then a business_transaction CI and a relation are not created. An example of the expected input message looks like the following xml (serialized by xmlout-plugin):

<message>
  <genint_meta>
    <integration_name>transaction_topology</integration_name>
    <integration_type>TOPOLOGY</integration_type>
  </genint_meta>
  <business_service>
    <business_service_id><![CDATA[700000000000000002]]></business_service_id>
    <business_service_name><![CDATA[TestService]]></business_service_name>
  </business_service>
  <business_transaction>
    <business_ transaction _id><![CDATA[700000000000000000]]></business_ transaction _id>
    <business_ transaction _name><![CDATA[testTransaction]]></business_ transaction _name>
    <business_service_name><![CDATA[TestService]]></business_service_name>
  </business_ transaction >
  ...
</message>

 

The transformed output message looks like the following (serialized by xmlout-plugin):

<message>
  <genint_meta>
    <integration_name>transaction_topology</integration_name>
    <integration_type>TOPOLOGY</integration_type>
  </genint_meta>
  <instance>
    <key><![CDATA[app:700000000000000002:TestService]]></key>
    <attributes>
      <ucmdb_data_externalid><![CDATA[TestService]]></ucmdb_data_externalid>
      <hpom_citype><![CDATA[business_application]]></hpom_citype>
      <hpom_discoTarget><![CDATA[BSM]]></hpom_discoTarget>
      <ucmdb_name><![CDATA[TestService]]></ucmdb_name>
      <ucmdb_description><![CDATA[Created by CA Wily]]></ucmdb_description>
    </attributes>
  </instance>
  <instance>
    <key><![CDATA[trans:700000000000000000:testTransaction]]></key>
    <attributes>
      <ucmdb_data_externalid><![CDATA[testTransaction]]></ucmdb_data_externalid>
      <hpom_citype><![CDATA[business_transaction]]></hpom_citype>
      <hpom_discoTarget><![CDATA[BSM]]></hpom_discoTarget>
      <ucmdb_name><![CDATA[testTransaction]]></ucmdb_name>
      <ucmdb_description><![CDATA[Created by CA Wily]]></ucmdb_description>
    </attributes>
  </instance>
  <relation>
    <parent><![CDATA[app:700000000000000002:TestService]]></parent>
    <generic>
      <containment><![CDATA[trans:700000000000000000:testTransaction]]></containment>
    </generic>
  </relation>
  ...
</message>

 

Metrics Transformation

This transformation is performed if an input message has the following properties:

integration-type: METRIC

An input message contains the CA Wily metrics. Since the WS plug-in node that consumes metric messages has better performance in case metric messages are not bulked, this transformation creates a separate message for each input metric. This means that, unlike the topology transformations that create one output message for each input message, this transformation can create thousands of messages per input message. An example of the expected input message looks like the following (serialized by xmlout-plugin):

<message>
  <genint_meta>
    <integration_name>metric</integration_name>
    <integration_type>METRIC</integration_type>
  </genint_meta>
  <metric>
    <agent_name><![CDATA[Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)]]></agent_name>
    <metric_name><![CDATA[Agents|solarwinds|.NET Process|PerfMonCollectorAgent.exe:Raw Metric Count]]></metric_name>
    <metric_value><![CDATA[440]]></metric_value>
    <end_time><![CDATA[2016-01-30T17:07:00.000Z]]></end_time>
  </metric>
  <metric>
    <agent_name><![CDATA[srv4|Tomcat|Tomcat Agent]]></agent_name>
    <metric_name><![CDATA[JMX|Catalina|name=HttpRequest4|type=RequestProcessor|worker=http-nio-8080:stage]]></metric_name>
    <metric_value><![CDATA[7]]></metric_value>
    <end_time><![CDATA[2016-01-30T17:07:00.000Z]]></end_time>
  </metric>
  ...
</message>

 

The transformed output message looks like this (serialized by xmlout-plugin):

<message>
  <genint_meta>
    <integration_name>metric</integration_name>
    <integration_type>METRIC</integration_type>
  </genint_meta>
  <BSMCMetric>
    <dataDomain><![CDATA[CA Wily]]></dataDomain>
    <timestamp><![CDATA[2016-01-30T17:07:00.000Z]]></timestamp>
    <value><![CDATA[440]]></value>
    <metricClass><![CDATA[Custom Metric Process (Virtual):Agents|solarwinds|.NET Process|PerfMonCollectorAgent.exe]]></metricClass>
    <metricName><![CDATA[Raw Metric Count]]></metricName>
    <relatedCI><![CDATA[Custom Metric Agent (Virtual)]]></relatedCI>
  </BSMCMetric>
</message>

<message>
  <genint_meta>
    <integration_name>metric</integration_name>
    <integration_type>METRIC</integration_type>
  </genint_meta>
  <BSMCMetric>
    <dataDomain><![CDATA[CA Wily]]></dataDomain>
    <timestamp><![CDATA[2016-01-30T17:07:00.000Z]]></timestamp>
    <value><![CDATA[7]]></value>
<metricClass><![CDATA[Tomcat:JMX|Catalina|name=HttpRequest4|type=RequestProcessor|worker=http-nio-8080]]></metricClass>
    <metricName><![CDATA[stage]]></metricName>
    <relatedCI><![CDATA[Tomcat Agent]]></relatedCI>
  </BSMCMetric>
</message>
...

 

Architecture

CA Wily plug-in is divided into several modules that are stacked on top of each other. This can be seen in the following figure:

HTTP Handler

This module is responsible for HTTP 1.0/1.1 communication. It uses libcurl underneath and synchronous IO operations. It supports the following features:

  1. Authentication against a remote server.
  2. Proxy support and proxy authentication.
  3. Currently it supports only unencrypted HTTP communication.

XML Handler

This module uses Xerces-C++ XML library in the background and acts as a façade around Xerces lower level function calls. It is able to parse the XML files and strings, building and printing the DOM trees and traversing the DOM trees using our custom XPath implementation.

XML Handler is used for the following:

  1. Getting the CA Wily SOAP request messages from the client requests file
  2. Parsing the CA Wily SOAP response messages
  3. Getting the required information for creating the output messages from CA Wily source nodes

Message Handler

The way XML handler is used for handling lower level XML. Message handler is used for GenInt message handling and acts around GenInt message lower level function calls. The main purpose of the message handler is traversing the GenInt messages using our custom XPath implementation. Message handler allows us to work with messages just like any other tree structures. It considers the GenInt message specific structures (message, attribute_group and attribute structures) just like ordinary tree nodes and simplifies message handling.

CA Wily Configuration

This is only a wrapper around GenInt configuration functions. Over GenInt built-in environment variable handling (${variable_name}) CA Wily configuration adds additional token handling:

  • @{ExecutionTimeInSec} – replaced with the current execution UTC time in seconds
  • @{ExecutionTimeInMin} – replaced with the current execution UTC time in minutes
  • @{LastExecutionTimeSec} – replaced with the last execution UTC time (in seconds) of the containing node
  • @{LastExecutionTimeMin} – replaced with the last execution UTC time (in minutes) of the containing node

In case timespan between execution time and last execution time exceeds the value specified for max-interval-window parameter, then the timespan is truncated (last execution time is updated to more recent time).

For more information on the usage of these tokens, see client-requests-file parameter.

CA Wily Client

This module is used to execute CA Wily SOAP operations. Every source node has its own CA Wily Client. Under the hood CA Wily Client performs these operations:

  1. Uses XML Handler to get the request SOAP message from the requests file.
  2. If the request SOAP message is parametrized (like in the case of metrics collection), then CA Wily Client uses CA Wily Configuration to replace parameters with their values from configuration.
  3. Uses HTTP Handler to invoke the CA Wily target service/operation.
  4. Uses XML Handler to parse the response and generate XML DOM tree, which is used later on to extract the required information from the response.

Message Transform

This module is used to execute the processing node transformations. Its business logic is explained in section CA Wily Processing Node. It uses Message Handler to move across message trees in a simple way.

CA Wily SOAP Source

This module represents the source node itself. It periodically executes the following source node business logic:

  1. Uses CA Wily Configuration to read the information about the underlying calls to execute. Many SOAP calls can be executed in sequence by a single source node.
  2. Uses CA Wily Client to execute the operation and parse the response for each operation.
  3. Uses XML Handler to extract the required information and add it to output message for each parsed response. For more information see nodes-level-[n] parameter.

CA Wily Processing

This module represents the processing node itself. It periodically executes the Message Transform job.

Send Help Center feedback