pub.flow:setResponse
WmPublic.
Deprecated - Replaced by
pub.flow:setResponse2.
Forces a specified response to be returned by the webMethods Integration Server to a calling process (such as a browser or application server).
Formatting of the response is normally handled by templates, which format values from the pipeline. If templates are not appropriate for a particular integration scenario, a response message can be created within the flow and then returned to the caller using this service.
Input Parameters
responseString | String. Optional. Response to be returned to the caller, specified as a string. |
responseBytes | byte[ ]. Optional. Response to be returned to the caller, specified as a byte array. |
string | Deprecated - Replaced by responseString. String. Optional. Response to be returned to the caller, specified as a string. |
bytes | Deprecated - Replaced by responseBytes. byte[ ]. Optional. Response to be returned to the caller, specified as a byte array. |
response | Deprecated - Replaced by responseString. String. Optional. Response to be returned to the caller, specified as a string. |
contentType | String. Optional. MIME type of the response data. By default, the server's response will match the MIME type of the request. This field allows this behavior to be overridden. Note: If you explicitly set this value with Designer, you will see two choices: text/XML and text/HTML. You are not limited to these two values. You may either select one of these or type a new value. |
encoding | String. Optional. Character set in which the response is encoded. |
Output Parameters
None.
Usage Notes
Specify responseString or responseBytes, but not both. If you specify both, the pub.flow:setReponse service uses responseString and ignores responseBytes.
If neither responseString or responseBytes are specified, Integration Server uses the value of the server configuration parameter watt.server.setReponse.pre82Mode to determine the order in which to look for and use the deprecated fields.
When watt.server.setResponse.pre82Mode is set to “true”,
Integration Server follows a precedence order similar to what was available in
Integration Server 7.1x and 8.0x. Specifically,
Integration Server looks for the deprecated parameters in the following order and uses the value of the first parameter that it finds:
response,
string,
bytesWhen watt.server.setResponse.pre82Mode is set to “false”,
Integration Server follows a precedence order similar to what was available in
Integration Server 8.2 and later. Specifically,
Integration Server looks for the deprecated parameters in the following order and uses the value of the first parameter that it finds:
string,
bytes,
responseOne possible usage of this service is to create an XML response to an XML request. A flow that creates an XML document by calling
pub.xml:documentToXMLString can use
pub.flow:setResponse to return the XML document to the caller. In your flow, you would map
xmldata (output of
pub.xml:documentToXMLString) to
responseString and set
contentType to text/xml (inputs to
pub.flow:setResponse). Calling
pub.flow:setResponse will cause the server to return the XML document that you've mapped to
responseString instead of processing the pipeline through a template.
Your client might be expecting binary data in the response, such as a JPEG image. In this case, map a byte array that represents the image to responseBytes and set contentType to image/jpeg.
Integration Server detects the type of request and sets the Content-Type value to text/XML (for requests in XML format) or text/HTML (for requests in all other formats). Be aware that if you specify a value for contentType, Designer will not able to decode or display output from flows that include this service. This is because your contentType setting will override the Content-Type value that the Integration Server uses to return output to Designer. If you use Run to test the flow, Designer will not display any results.
If you specify a contentType value that is not supported, Integration Server sets the Content-Type of the response to text/XML.
If the
contentType input parameter and the Content-Type header of the request are not set,
Integration Server uses the value of the request Accept header to set the Content-Type header of the response. For more information about how
Integration Server handles Accept headers to set Content-Types, see
the section Accept Header Field in the webMethods Integration Server Administrator’s Guide.
Accept Header Field.Keep in mind that when returning the processed XML document to the client that originally submitted it, you may need to modify the encoding. Java String objects are always stored using a Unicode encoding. If your original XML document used an encoding other than UTF-8 or UTF-16, it will still contain an encoding tag that indicates what this encoding was. However, if you did not modify the encoding during document processing, you need to set the encoding parameter when you invoke the pub.flow:setResponse service. Specifically, do one of the following:
Set the
encoding parameter to match the tag in the file, or
Set the
encoding parameter to "autoDetect" to use the encoding specified in the XML string encoding tag.