Websydian v6.1 online documentationOnline documentation - WebsydianExpress v3.0

Development upgrades to WebsydianExpress v3.0

CA Plex Upgraded

Development in CA Plex with WebsydianExpress v3.0 requires CA Plex v6.0 or v6.1. We recommend using CA Plex v6.1.

Java version 1.5 or later

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.

Local model configuration

New versions have been added to all Websydian patterns and new objects have been supplied with WebsydianExpress v3.0.

Generate and Build

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.

Deprecated API's

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:

  1. Perform a usage check on each of the deprecated API's scoped to the WSYAPI/_Deprecated
  2. Generate all your source code and do a search in the source code for _Deprecated

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

Changes to Abstract functions

PageGeneratorForProcess

Fields WorkFields.ApplicationURLHttp and WorkFields.ApplicationURLHttps have been removed from WsyDetails and WsyGrid

To add them back do the following

  1. Add the WorkFields.ApplicationURLHttp and WorkFields.ApplicationURLHttps to the variables WsyDetails and WsyGrid
  2. In the Post Point End Initialize add
    Cast WsyDetails<WorkFields.ApplicationURLHttp>, APIServer.GetBasicSessionData/Output<APIFields.HttpUrl>
    Cast WsyDetails<WorkFields.ApplicationURLHttps>, APIServer.GetBasicSessionData/Output<APIFields.HttpsUrl>
  3. In the Pre Point 0 Load fields in grid add
    Set WsyGrid<WorkFields.ApplicationURLHttp> = WsyDetails<WorkFields.ApplicationURLHttp>
    Set WsyGrid<WorkFields.ApplicationURLHttps> = WsyDetails<WorkFields.ApplicationURLHttps>

Call back functions

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.

Identifying the relevant 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).

Changing the inheritance

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

Handle parameters

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>.

Generate and build the callback function

You need to regenerate and build the callback function.

You must also deploy the new function to the upgrade environment.

Define the callback function for the callback point

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.

Special case for IsSessionInIntranet

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).