I have created a flow service which will be called by a C# application. Currently I have set up the flow service to take a node or xmldata string per suggestions in a previous post. I created a HTTP URL alias in the properties. This works great but now I am being asked to make this a SOAP and/or RESTv2 call. When I do this then the only thing which shows up in the WSDL and Swagger is node and xmldata. Should I revamp my flow service which I just finished to use the Document Type as a refence in the input. If I do this then it really hoses up things downstream although I have some ideas on getting around it (maybe). Or should I create a wrapper that takes my document type request and convert it to a node then call my service?
In a flow service that is going to be a SOAP or RESTv2 service should I always have my input be the specific Document Type request, or how do you handle the scenario of using node object and xmldata string? Probably a very dumb (newbie) question, but I figured I would ask the experts so I am not wasting time. Thank you.
Hi Chris,
The whole beauty of webMethods is that you don’t need to care about the format of the data. Whether it is xml, json etc. etc. Simply define the signature of the service based on simple types such as Strings, Integers etc or even complex document types.
As long as the client provides the correct content type whether it is application/json or text/xml, the server itself will decode the payload to your service. Obviously if the caller omits fields then you will need to validate that but that’s it.
This equally applies to your response. Simply return a document from your service, it will then get converted automatically to either the same format as the request or if they have specified an Accept header.
If your service has a proper signature any API or soap descriptors will be properly documented with the swagger defining the proper json structure including whether attributes are optional, mandatory etc.
This decoupling is great because a service developed 5 years ago and used in a SOAP scenario can be called via a REST API, by simply creating and API resource and descriptor with zero code changes!
@John_Carter4 are you saying I would not have to do the following:
The MAP would link the input document reference to the document. Probably not necessary but unsure. If I don’t add a reference to the document type I created as an input variable to the flow then the swagger in the REST API Descriptor would only show the node and xmldata. Although I think doing this would also create some confusion. Maybe I should just have the input variable for the flow being the Document Type I created versus adding in node or xmldata. Thoughts?
Quite right, you don’t need any of the code mentioned.
Simply specify the document type as a reference type in the input of the service.
When calling the service externally, set the Content-type: text/xml
that’s it
You can do the same with a client using json format, just simply set the Content-type to ‘application/json’
If you don’t want to create your own test data manually, simply do the reverse, create a flow service that leaves a document in you pipeline at the end with all attributes properly populated. Then call if from a client, specify the required ‘Accept’ header and you will see an xml or json formatted sample returned to you.
