Previous Topic: Payload Mapping FileNext Topic: CTG Copybook

Using CA Service Virtualization › Using the Workstation and Console with CA Service Virtualization › Creating Service Images › Using Data Protocols › Copybook › Matching Logic

Matching Logic

You can determine how the matching logic works based on the descriptions of the XML elements and arguments. However, to provide a clearer picture, this section explores matching fully.

When VSE receives a payload, matching occurs in the following phases:

 

Payload

Payload is the first phase of matching that happens when VSE receives a new payload. This phase determines which <payload> element from the payload mapping file corresponds to the payload received. VSE tries to match a <payload> element by processing the elements in the payload mapping file in order, from top to bottom. The first match wins.

Note: If no payload elements match the payload, it is treated as an "unknown payload." The content is HEX encoded, and it is wrapped in a generic XML structure. If necessary, unknown payloads are automatically converted back to bytes during playback.

For the Request payloads:

  1. If the type attribute of this element is "request," proceed. Otherwise, this element does not match.
  2. If the matchType is argument, look for a request argument with a key that matches the key attribute from this element and a value that matches the value attribute from this element. If one is found, this payload element matches.
  3. If the matchType is attribute, look for a request attribute with a key that matches the key attribute from this element and with a value that matches the value attribute from this element. If one is found, this payload element matches.
  4. If the matchType is metaData, look for a request metaData entry with a key that matches the key attribute from this element and with a value that matches the value attribute from this element. If one is found, this payload element matches.
  5. If the matchType is operation, verify whether the operation name for the request matches the key attribute from this element. If so, this payload element matches.
  6. If the matchType is payload, search in the boundary that is specified by this element's keyStart and keyEnd attributes for the value in the key attribute. If the key is found in those bounds, the payload element matches.
  7. If the matchType is all, Steps 2 through 6 are processed in order, stopping when a match is found. The only variation is that in Steps 5 and 6, the value attribute is used in place of the key attribute.

For the Response payloads (during recording):

  1. If the previously seen request payload element set the definesResponse attribute to true, immediately return the payload element with the same name as the request element, but with a type of response. If no such element is found, there is no match.
  2. If the previously seen request payload element did not set the definesResponse attribute to true:
    1. If the type attribute of this element is response, proceed. Otherwise, this element does not match.
    2. If the matchType is metaData, look for a response metaData entry with a key that matches the key attribute from this element and with a value that matches the value attribute from this element. If one is found, this payload element matches.
    3. If the matchType is payload, search in the boundary that is specified by this element's keyStart and keyEnd attributes for the value in the key attribute. If the key is found in those bounds, the payload element matches.
    4. If the matchType is all, complete Steps b and c in order, stopping when a match is found. The only variation is that in Step c, the value attribute is used in place of the key attribute.

For the Response payloads (during playback):

During playback, no matching is done for responses. Instead, during recording, whatever match was determined is saved in the Metadata of the Response object. Then, during playback, when that Response object is returned, the processor picks up the value from the Response Metadata, finds the payload element with that name (and type="response") and uses it. If no such element exists, it is considered an unrecoverable error.

 

Section

After the payload element is identified, the processor reviews each section element in order, from top to bottom. No matching is done at this level. After the processor has fully processed a section (that is, when none of the copybooks in the section match), it proceeds to the next section and does not revisit previous sections.

 

Copybook

The final phase of matching is to determine which copybook in this section applies first, second, and so on, until all the records in the payload are processed. This phase is the most complex matching phase. The process is:

  1. The processor reviews all of the copybook elements in the section and sorts them by the number that is specified in the order attributes.
  2. The list of copybook elements with the lowest order number is checked first (in the order the file specifies them). The remaining payload is searched for the value in the key attribute for this copybook element and the index where it is found (if at all) is saved. The remaining payload is searched for the value in the key attribute for this copybook element and the index where it is found (if at all) is saved.
  3. After all copybooks in the lowest order list have been checked, if any matched, the one found earliest in the payload is used.
  4. If a copybook matched:
    1. If the matching copybook has matched this payload previously (an earlier record in the payload), the max attribute is checked to see if it can be applied again. If the max has been reached, this is not considered a match and the next matching copybook is used.
    2. If the max has not been reached, this copybook is applied to the payload and the number of bytes specified by the copybook is consumed. If there is a length-field attribute on the copybook, the value of that field in the record is used to determine how many bytes to consume and the processor returns to Step 2.
  5. If a copybook did not match, the list of copybooks with the next lowest order number is checked using the same rules as Steps 2, 3, and 4. After the processor decides that no copybooks in an order number list match, it does not try to process that order number list (for this section) again for this payload.
  6. After all lists are checked and no matches are found (or the payload runs out of bytes), the processor proceeds to the next section.

 

Finalizing

If bytes are left over in the payload after all sections for a payload have been processed, they are truncated.