|
|
| Severity | High |
|---|---|
| Product | Websydian TransacXML |
| Websydian version | 6.1 (when upgrading from earlier versions) |
| Plex version | All |
| Platform | All |
| Category | TransacXML |
| Problem | In Websydian version 6.1, a new source code SOAPAction, which
is scoped by the XMLHandlers has been introduced. This enables the
developer to give a SOAPAction to an XMLHandler that does not
conform to the specification for a Plex name.
This feature does not disable the earlier way to determine the use of the implementation name of the XMLHandler as the SOAPAction - as long as no value is specified in the source codes, the implementations names are used instead. However, an error occurs when you have more than one XMLHandler assigned to your SoapProcessor. When the XMLHandler specified by the last SoapProcessor comprises FNC XmlHandler triple is called, all of the XMLHandlers comprised by the SoapProcessor is called in succession - the SoapProcessor will return the response document from the first XMLHandler. |
| Answer | The reason for this is an unexpected behavior of the Plex meta statement ++Text Defined (which is used to retrieve the value specified in the source code). If no value has been specified in the source code, this does not return blank - it does not even create an assignment statement in the generated code. |
| Workaround | There are two possible work arounds (you only have to implement
one):
1. For all XMLHandlers: Specify the implementation name of the XMLHandler as the literal value of the SOAPAction sourcecode scoped by the XMLHandler. 2. In the SoapProcessor action diagram - Pre Point Start work with SOAPAction target function (In the subroutine "Work with SOAPAction target function") add the code: Set Local<CatalogTarget> = <CatalogTarget.*Empty> |
Online documentation - Websydian v6.5