Online documentation - WebsydianExpress v3.5 |
Development in CA Plex with WebsydianExpress v3.0 requires CA Plex v6.0 or v6.1. We recommend using CA Plex v6.1.
All java programs supplied with WebsydianExpress v3.0 now requires Java version 1.5. This means that you need to make sure that java version 1.5 or later is available on your development and production environment.
New versions have been added to all Websydian patterns and new objects have been supplied with WebsydianExpress v3.0.
During development of WebsydianExpress we do our outmost to support backward versions of WebsydianExpress business process but in some situations we require that all business processes are generated and build. The requirements for generate and build varies from platform to platform, please read below.
In general we recommend that all functions are generated and build when upgrading to a new version of WebsydianExpress.
All deprecated API's are scoped to the function WSYAPI/_Deprecated.
In order for you to identify what deprecated function you are using you have two options:
The following API's have been deprecated and moved to WSYAPI/_Deprecated in WebsydianExpress v3.0. In most cases a new API have been made available.
Deprecated API (WSYAPI/_Deprecated) | New API (WSYAPI) |
---|---|
APIServer.GetEventInformation | No new API - Check new message log API's and functionlity |
APIServer.GetEventTypeForEvent | No new API - Check new message log API's and functionlity |
APIServer.Session.Create | SystemAPI.API.Session.CreateSession |
APIServer.Session.CreateValidation | No new API |
APIServer.Session.Update | APIServer.Session.Update |
APIServer.Session.UpdateValidation | APIServer.Session.UpdateValidation |
APIServer.GetBasicSessionData | APIServer.Session.GetBasicSessionData |
APIServer.GetSessionData | APIServer.Session.GetSessionData |
Fields WorkFields.ApplicationURLHttp and WorkFields.ApplicationURLHttps have been removed from WsyDetails and WsyGrid
To add them back do the following
The callback functionality that was available in the previous versions was found by some customer to be to limiting for their purposes. As a result of input from these customers we have reworked the way callback functions are handled.
These changes means that if you have replaced a callback function with your own implementation, you need to change your functions.
The way callback functions previously was implemented was by letting the custom implementation of the callback function inherit from the one delivered as part of WebsydianExpress and giving the function the same name as the delivered one.
This means that you can find the custom made implementations of the callback functions by investigating the usage of the functions scoped by the function CallfackFunctions in WSYAPI (version 2.x - in version 3.0, these abstract functions has been moved to _Deprecated.CallbackFunctions).
In WSYAPI for version 3.0, you will find a new set of functions that handles the callback functionality. These functions are scoped under the function Callback.
You need to change the inheritance from the old version callbackfunction (now scoped under _Deprecated.CallbackFunctions) to the corresponding new function.
So if you have created a function MyUserAfterLogin in version 2.1 - you will have the following definitions:
Source Object | Verb | Target Object |
---|---|---|
MyUserAfterLogin | is a FNC | CallbackFunctions.WebServer.UserAfterLogin |
MyUserAfterLogin | impl name NME | WSUSAFLO |
After upgrading the model this will have changed to:
Source Object | Verb | Target Object |
---|---|---|
MyUserAfterLogin | is a FNC | _Deprecated.CallbackFunctions.WebServer.UserAfterLogin |
MyUserAfterLogin | impl name NME | WSUSAFLO |
Change the inheritance to:
Source Object | Verb | Target Object |
---|---|---|
MyUserAfterLogin | is a FNC | Callback.WebServer.UserAfterLogin.AbstractCallbackFunction |
The way parameters are transferred to the callback functions has been changed to facilitate the dynamic calls that is a feature of the new functionality. The parameters are no longer available in the Input/Output variable groups, instead they are available in the local variables CallbackInput and CallbackOutput respectively. This means that each time you refer a parameter in your program you have to change the mapping to using the local variables instead.
The following callback functions has parameters:
BeforeRequestStart
IsSessionInIntranet
SessionAfterCreate
UserAfterCreate
UserAfterDelete
UserAfterLogin
UserValidateBeforeCreate
UserValidateBeforeDelete
UserAfterLogin has one parameter - the session surrogate is an input field.
To handle this parameter, open MyUserAfterLogin. Plex will show an error for each usage of the input parameter.
Change the mapping from Input<APIFields.SessionSurrrogate> to CallbackInput<APIFields.SessionSurrogate>.
You need to regenerate and build the callback function.
You must also deploy the new function to the upgrade environment.
Instead of replacing existing objects, version 3.0 lets you declare a list of callback functions to call for each callback point.
You do this in the administration interface (Menu item Site configuration →Callback functions).
As soon as the callback function is defined it will be called if the callback point is reached. This means that you must deploy the new function before adding it to the callback point.
This callback function is a bit special in that it in version 2.1 replaced an object that did perform the standard intranet check.
This means that you can keep the existing object - if you do so, any definitions you add to the IsSessionInIntranet callback point will have no effect.
In general we recommend that you change the inheritance as shown above - and add it to the callback point in the administration interface.
For this callback function you must also change the implementation name - and ensure that you remove the generated object from you application library/folder (otherwise the old object will be used).