Service Virtualization

Hi Joel/Monalisa, J_NeSmith, Monalisa.Nayak

I am creating a VS where I am using Copybook data protocol and request contains Header and Payload. So I have added both Copybooks in Payload-Mapping files as follows

1)

Under RequestPayload I have added two sections as follows.

   <Section name="body">

<copybook order="1"> PayloadCopybook name</copybook>

</Section>

<Section name="body">

<copybook order="2> Header Copybook name</copybook>

</Section>

Outcome:

VS is not able to convert the request and showing as "unknown-payload"

2)

Under RequestPayload I have added both copybooks under same sections as follows.

   <Section name="body">

<copybook order="1"> PayloadCopybook name</copybook>

<copybook order="2> Header Copybook name</copybook>

</Section>

Outcome:

VS is able to recognize/convert the request which is available in first <Section>

Kindly suggest me.

Thanks,

Narasimha.

Is it possible for you to upload a copy of a request and the two copybooks? If you upload, please replace any identifying information while leaving the content alignment such that it maps to the copybook. I would like to see the format of the request relative to the mapping. 

Hi Joel,

I have attached sample request response, copybooks and Mapping files.Thanks

Regards,

Narasimha

Take a look at the attached DT project file. I tried to chain the copybooks together such that the header copybook goes first and occurs only once followed by the payload. The mapping document looks like this:

The following graphic is excerpt showing the VSI mapping the two copybooks as depicted by the highlighted parts which show the end of the Header payload and beginning of the Request body payload:

I only applied the Copybook DPH so the operation in the sample VSI shows as <unknown-op>.

The Copybook mapper did not process the response correctly.

I believe your request and response sample data contains different codepages and this caused an error parsing the response.

The highlighted area in the response below looks as if it contains non-ASCII text data. Since the request was clear text ASCII, it seems to have parsed properly. I suspect the lack of a codepage conversion caused the response to map as unknown copybook.

.

I hope this helps get you started on the solution.

Thank you so much Joel.. I am able to see that EBCDIC request is getting converted into XML format after making changes to the Payload-Mapping file as per your suggestion. However, response is not getting converted into readable format because of Non-Hex values. And I was told that request will contain Non-Hex values as well. Is there a way to parse Non-Hex values as well.

Once again thanks a lot for your quick response.

Regards,

Narasimha.

Keep in mind that the service and DPHs need to process requests / responses exactly as they appear in the live system at run-time. I believe the messages are transporting in binary (EBCDIC) not UTF format. This means the service needs to deal with the messages as if they are binary.

However, the R/R pairs in the example appear to have been converted into UTF format. So, I built the mapping using UTF encoding not binary encoding (IBM037). To get the service to align with the real system's expectations, we need to ensure that the R/R pairs we are generating the service from match exactly to messages the service will see at run-time.  (Hopefully, this is making sense.)

Approach:

Try copying the the R/R pairs from the mainframe to the file system as binary files (like you would if this were an EXE file) so that no ASCII conversion is applied. Then, use the R/R pair recorder and specify the encoding in the Copybook DPH as IBM037 so DevTest knows it needs to convert the request / response to  ASCII at run-time. (See Encoding below). Do this for both the Request and the Response side Copybook DPHs.

This approach may straighten out the conversion so the response-side copybooks map.

If this does not work, it is best to open a ticket with CA Support so they can help you diagnose the issue.