Let's take a look at what each of the DPHs is doing. Without any modifications, let's send the first request (Request used for implementing the virtual service).
After the SOAP DPH executes, the incoming request looks like this:
Operation = "process" - taken from the Soap Body
Arguments = "" - the Soap DPH does not parse the header and there are not body elements except for the [CDATA] to the argument list is empty
Conversely, if you were to use the SOAP Headers DPH, the headers would be extracted and you could skip the XML DPH moving straight to the Scriptable which sets up for the JSON parsing.
After the XML DPH executes, the incoming request looks like this:
Operation = "Envelope" - XML takes the root element and makes it the operation
Arguments =
Header_WFContext_messageId=XXXX
Header_WFContext_sessionId=***
Header_WFContext_creationTimestamp=xxxx
Header_hulaContext_version=0
Body_process=<![CDATA[{"request":{"id":"1000"}}]]>
After the RDM DPH executes, the incoming request looks like this:
Operation = null - because Header_hulaContext_action is not included in the XML sample
Arguments =
Header_WFContext_messageId=xxxx
Header_WFContext_sessionId=***
Header_WFContext_creationTimestamp=xxxx
Header_hulaContext_version=0
There is no Body_process=...[CDATA] because the RDM "moved" this argument to the request body.
After the Scriptable DPH executes there is no net change in the argument list or in the Operation name. The Scriptable is setting up the Body for the JSON DPH.
After the JSON DPH executes, the incoming request looks like this:
Operation = null
Arguments =
Header_WFContext_messageId=xxxx
Header_WFContext_sessionId=***
Header_WFContext_creationTimestamp=xxxx
Header_hulaContext_version=0
request_id=1000
Therefore, the VSI needs to contain an Operation of NULL and the above argument list in order to complete the exact matching logic.
Now, let's repeat the same steps and look at the XML sent during the API call from the consumer.
Soap DPH results:
Operation = process
Arguments = ""
XML DPH results:
Operation = "Envelope" - XML takes the root element and makes it the operation
Arguments =
Header_WFContext_type=***
Header_hulaContext_version=0
Body_process=<![CDATA[{"request":{"id":"1000"}}]]>
RDM DPH results:
Operation = "null"
Arguments =
Header_WFContext_type=***
Header_hulaContext_version=0
Scriptable causes no change, just set up for JSON
JSON DPH executes:
Operation = "null"
Arguments =
Header_WFContext_type=***
Header_hulaContext_version=0
request_id = 1000
Let's compare the argument list in the VSI to the two incoming requests.
The sample VSI is performing Signature matching, therefore, the signature of the incoming request must match the VSI.
Given the operation is null, the VSI should be throwing the Service Image Not Found Response - but let's assume the sample XML is missing some XML elements.
| Request 1 Arg List | Request 2 Arg List | VSI Expected Signature (i.e., Arguments) |
|---|
Operation = null Args: Header_WFContext_messageId=xxxx
Header_WFContext_sessionId=***
Header_WFContext_creationTimestamp=xxxx
Header_hulaContext_version=0
request_id=1000
| Operation = null Args: Header_WFContext_type=*** Header_hulaContext_version=0 request_id = 1000 | Operation = customerRequest Args: Header_WFContext_messageId Header_WFContext_sessionId Header_WFContext_creationTimestamp Header_WFContext_activitySourceId Header_WFContext_hostName Header_WFContext_originatorId Header_WFContext_originatorIdType Header_WFContext_initiatorId Header_WFContext_initiatorIdType Header_WFContext_service Header_WFContext_processingMode Header_WFContext_contextType Header_hulaContext_service Header_hulaContext_password Header_hulaContext_keyword Header_hulaContext_behaviorVersion customerRequest_id |
| | |