In the context of migrating existant web-services from CICS to Tuxedo/SALT, I have two questions :
1 - Is there a way to "automatically" map a complexType to a buffer where the data will be layed out as expected by a Cobol structure equivalent to the complexType?
The main reason is to avoid having to "parse" the FML32 buffer in order to recompose the data that will be given as input to the Cobol programs of the web-service.
2 - Since it is about migrating existent services, we have some cases where sub-elements have the same names. This was not causing an issue on CICS. When doing some preliminary tests on SALT, we get the following warning:
WSDLCVT:26:WARNING: More than one field with different fullname or schema have the same name. Please resolve the naming conflict. ...
When the duplicate names are in different elements used separately in request/answer , it worked OK.
However, we have some cases when the duplicates are on a same complexType...
Is there a workaround to this or it is planned to remove this constraint in a future release of SALT.
OK, I'm not sure I'm understanding exactly what you are trying to do. Can you describe in a bit more detail the before environment and the after environment? Do you have existing COBOL code that is accessed as a web service from somewhere else? Or is the COBOL code trying to call an external web service? Are the existing services written in COBOL? If you can provide some more details, I can likely provide some suggestions.
Oracle Tuxedo Chief Architect
Thanks for your answer, here are some additional clarifications :
The before environment : CICS with Cobol programs accessed as Web-services
The target environment : Unix/Linux, Tuxedo with Microfocus Cobol programs migrated using ART.
We have both situations :
- Existing COBOL code that is accessed as a web service from somewhere else (this is the most frequent situation)
- Existing COBOL code that invokes external web-services (just a few cases of this kind)
The input/output data is provided/returned by using CICS containers and is seen from a Cobol point of view as a classic Cobol structure.
So mainly for the first kind, we would like to be able to map automatically the input/output data to the same cobol structure layout.
Tuxedo ships with a tool that can convert COBOL copybooks to Tuxedo VIEW/VIEW32 buffers. Using SALT, the migrated services can be directly accessed by SOAP/HTTP clients without any code changes to the COBOL programs as SALT supports mapping VIEW/VIEW32 buffers to SOAP and back.
The outbound calls are a bit more difficult because the buffer type used for outbound calls is FML32 as it is the only buffer type that can match the shape of the XML document required to make the outbound SOAP call. My recommendation would be to create a simple proxy service in Tuxedo that takes the VIEW/VIEW32 buffer the COBOL code is currently creating to call the external web service and map that to FML32. Depending upon the mapping requirements, it's possible the mapping could be done with a single call to the FML function that converts a VIEW/VIEW32 buffer to an FML32 buffer, but that would depend a lot on the mapping that needs to be done. In fact, if this is later option will work, it could be done right inside the COBOL program using the FVFTOS32 and FVSTOF32 COBOL APIs provided by Tuxedo.
Oracle Tuxedo Chief Architect