|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
Upgrade Overview
This section includes a description of the changes in the TransacXML Web Service patterns in Websydian 5.5.
For upgrade instructions please go to the next section. It is recommended to go through this section in order to get an overview of the changes before continuing with the upgrade instructions in the next section.
The following variables used by the SoapProcessor and SoapGenerator functions have been renamed:
| Old name | New name |
|---|---|
| Header | SimpleHeaderElements |
| HeaderElements | ComplexHeaderElements |
The SoapProcessor, SoapGenerator, and ExtractSOAPBody functions have been restructured in Websydian 5.5. In this process some code and edit points have been removed from these functions. If code has been inserted in any of the deleted edit points it should be examined whether this code is still necessary and, if yes, then which edit point the code should be moved to.
In previous versions of TransacXML Web Services the SOAP message was handled incorrectly:
When receiving a SOAP message the SOAP payload was considered to be the SOAP Body element and this element was then renamed to default.
The above had two serious effects:
TransacXML web services could not communicate with other web services without modification.
In Websydian 5.5 this has been fixed so XML documents are sent and received correctly. This also means that all previous local modifications regarding this issue inserted in the SoapGenerator, SoapProcessor, and ExtractSOAPBody functions can be removed.
The general rule is that it should no longer be necessary to add any code to the SoapGenerator, SoapProcessor, or ExtractSOAPBody functions.
Implementing a web service oriented application in previous versions of Websydian required that one of the following Websydian patterns where implemented:
WSYSOAP/_Abstract.SoapWithHeaders
The distinction between an implementation with or without headers has turned out to be unnecessary and confusing, so the above patterns have been merged into two base patterns:
WSYSOAP/_Abstract.Soap
If you have inherited from any of the patterns with headers, the inheritance should be changed to the corresponding entity without the WithHeaders extension.
Any modifications that have been applied to the SoapProcessor due to any of the following bugs can safely be deleted:
Remove quotes from SOAPAction value.
In most web service implementations the SoapProcessor does not need any modifications to the action diagram. This means that most likely all previous modifications to the SoapProcessor action diagram can be removed. If in doubt please contact Websydian Support for advice.
Please note that some of the above bugs also implied modifications to the Services.ExtractSOAPBody action diagram. These changes should also be deleted.
The SoapProcessor has a function option named ServerValidation. This option determines whether it is the SoapProcessor (server) or the XmlHandler that should perform request specific validation of the message.
If it is the XmlHandler that validates the request then the SoapProcessor will make two calls to the XmlHandler function: One call for validating the request and one call for processing the request.
In previous versions of Websydian this option was set so the XmlHandler validated the request. This has changed so it is up to the SoapProcessor to validate the request and thus the XmlHandler is called only once.
| Option ServerValidate set to | Edit point to insert validation code |
|---|---|
| Yes (default) | "Insert call to validation function" in SoapProcessor |
| No | "Subscriber validation functionality" in XmlHandler |
In most cases no extra validation has been inserted so this change should not affect existing applications.
In previous versions of Websydian temporary XML documents where written to the disk when the XML documents where transferred between function calls. For performance and usability this has been changed so temporary XML documents are kept in memory.
The value in the message object SoapProcessor.Messages.DefaultSaveDir has been changed. The previous value was "c:\temp" and it has now been changed to the empty string. This has the effect that temporary files by default will be written to the current directory of the application. However, this value is in most cases overwritten by the settings in the configuration file.
The entries in the configuration file has been renamed so the names explain more about the purpose of the entries.
The handling of the optional SOAP headers have been changed in Websydian 5.5. If the SoapProcessor must process any optional SOAP headers in the SOAP messages, then please consult the documentation for the SoapProcessor for information on how to do this.
The SoapProcessor has been changed in the way it transfers XML documents to the XmlHandler. In previous versions of Websydian this was done using files, where the filename of the XML documents where transferred as parameters between function calls.
This has now been changed so the XML document is kept in memory and instead the doucment object references are transferred between function calls.
Depending on how the XmlHandler is coded there are several ways to upgrade the XmlHandler to Websydian 5.5. Please consult the Upgrade Instructions for more details.
All modifications that have been applied to the SoapGenerator due to any of the following bugs can safely be deleted:
Surround SOAPAction value with quotes.
In most web service implementations the SoapGenerator does not need any changes to the action diagram. This means that most likely all of the previous changes that has been inserted in the SoapGenerator action diagram because of bugs can be removed. If in doubt please contact Websydian Support for advice.
Please note that some of the above bugs also implied modifications to the Services.ExtractSOAPBody action diagram. These changes should also be deleted.
The interface for the SoapGenerator function has been changed. A major change is that in previous versions of Websydian the SoapGenerator used files to store the XML documents for the request and the response payloads. This has now been changed so the SoapGenerator as input expects the object references to the XML document that should be sent and to the XML document where the returned SOAP payload should be written.
The handling of the optional SOAP headers have been changed in Websydian 5.5. If the SoapGenerator must process any optional SOAP headers in the SOAP messages, then please consult the documentation for the SoapGenerator for information on how to do this.
The entries in the configuration file (Windows INI file/Java property file) has been renamed so the names explain more about the purpose of the entries.
The SoapGenerator now checks the HTTP status code of the returned HTTP response. If the status code is different from 200 (OK) then the response is not treated as a valid SOAP message.
This change does not require any modifications to the model.
Continue with Upgrade Instructions.
Online documentation - Websydian v6.0