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

WebsydianExpress 1.2 - What's New?

WebsydianExpress for 2E

2E Developer for WebsydianExpress provides you with the means to develop business processes using 2E.

You can find more information in 2E Developer for WebsydianExpress.

Development

Location of WebsydianExpress Database

This only applies to WebsydianExpress for Plex/Websydian.

In previous versions of WebsydianExpress the location of the WebsydianExpress database was specified at development time by setting the variant for the STORAGE library model. This was a problem if the WebsydianExpress database was not stored on the same platform as the back-end database. E.g. if the WebsydianExpress database is located on a Microsoft SQL Server and the back-end database on an iSeries.

This has been solved by introducing a variant for the WSYAPI library model. At development time this variant should be set to the platform type where the WebsydianExpress database is installed.

New Callback Functions

New callback functions have been introduced:

ApplicationServiceStart Invoked for each application service at startup. The callback function can be used to perform per application service specific initialization; e.g. connecting to back-end resources.
ApplicationServiceEnd Invoked for each application service when terminated. The callback function can be used to perform per application service specific cleanup; e.g. disconnecting from back-end resources.
HandlingRequestStart Invoked when a request is received by the application service.
HandlingRequestEnd Invoked when the application service has processed a request.

More information can be found in Callback Functions.

Miscellaneous

Backward Compatibility

Business processes developed for WebsydianExpress 1.0 and 1.1 can be deployed in WebsydianExpress 1.2 without regenerating and recompiling the business processes.

Refresh Browser at Session Timeout

Due to the use of frames and browser caching it could be difficult for users to refresh the browser window with a new session once a session was timed out. Often the quickest solution was to close the browser and open it again.

This problem has now been solved by introducing a special ErrorPage which is called when a session is timed out. This ErrorPage includes a link which will refresh the browser window with a new session, allowing the user to quickly reload the application in the browser when a session is timed out.

Operation

A restart command has been introduced which will restart the application services one at a time. This makes it possible to restart WebsydianExpress in a controlled way without stopping WebsydianExpress, thus making sure that user requests still are served.

This is useful if updated objects have been deployed (program objects, database files, etc...) and the system must be restarted so the updated objects will be used.

Bug Fixes

Returning status of SessionCreate

APIServer.SessionCreate did not set *Returning status if an error occurred when creating a session.

This has now been fixed.

Menu services on login page

Due to a bug it was not possible to use menu services on the login page.

This has now been fixed so menu services can be inserted on the login page. This is useful for inserting a link to a user self-registration business process allowing the user to register if not already registered.

You can read more about menu services in Using a Menu Item Outside Menus.

Error messages in event registration

The error messages written to the message log if the registration of an unknown event fails have been improved. This should make it easier for a developer or an administrator to identify the cause of the failure and how to resolve the error.

Message to Message Log if no Site Element for Menu Service Alias

If a menu service alias is used on a template, but the alias not has been associated with a site element, then an error message is now written to the message log so an administrator can take action and resolve the error.

Distributed Websydian Architecture (DWA)

DWA is the runtime architecture which WebsydianExpress is built on. This section describes the changes that have been made to DWA which are visible for the administrator of a WebsydianExpress installation.

Web Server Component for iSeries

A new web server component for the iSeries platform is included with the Websydian distribution. The Web Server Component for iSeries is based on the CGI standard and can be deployed on IBM iSeries HTTP Server or IBM Apache Web Server for iSeries.

The Web Server Component for iSeries can be used as an alternative to the Servlet Web Server Component which must be deployed on WebSphere.

You can read more in Websydian Web Server Component For iSeries - Deployment.

Rolling Log

When setting up the log files for the Servlet Web Server Component or the Websydian Server it is now possible to specify that the log file should roll after a specified period (hourly, daily, weekly, or monthly).

This feature ensures that log files never get too big.

You can read more in Servlet Relay Service Options or Websydian Server Options.

Better Handling of Application Service Errors

The Servlet Web Server Component has been improved so if an error occurs when a request is sent to the application service, then the Servlet Web Server Component will now use another application service instead of aborting further processing of the request.

This gives a better user experience in case of errors.

Improved Start Up Sequence

At startup an application service will connect to the Websydian Server to register itself. This requires that the Websydian Server is started before the application services.

To improve the stability of startup scripts, the application service now try to reconnect to the Websydian Server if the first connection attempt fails.

The application service will attempt to connect 3 times and pause in 30 seconds between each connection attempt before it fails to startup.

Error Messages Improved and Error ID

The error messages written to the DWA log files (Servlet Web Server Component log and Websydian Server log) have been improved so they more clearly state the most likely cause of the error and how to resolve them.

If an error happens in the Servlet Web Server Component then for security reasons no information about the error will be sent to the browser. Instead an error ID is written to the page, and this error ID can be used to search the Servlet Web Server Component log for the cause of the error.

Backward Compatibility for Websydian Server

The Websydian Server is backward compatible with Websydian applications developed with Websydian 5.5 and Websydian 5.6.

This is useful if you have several applications that use the same Websydian Server, and you do not want to upgrade all applications to Websydian 5.7 in one step.