Upgrade notes for Websydian v6.1.4

TransacXML issue when upgrading to 6.1 solved

An issue involving call of XMLHandlers from the SoapProcessor when upgrading from versions prior to v. 6.1 to version 6.1/6.1.1/6.1.2/6.1.3 has been identified.

The issue and the workaround is described here.

This issue has been solved in version 6.1.4 so the work around is no longer necessary.

The described workarounds and the fix implemented in version 6.1.4 can coexist.

Changes to _DocumentTemplateGenerator

In all previous versions, the DocumentTemplateGenerator function inherited from the scoping PageGenerator function. This inheritance made it possible to retrieve information from the PageGenerator so that the template could be generated.

This inheritance had the unfortunate side-effect that every time you scoped anything under the PageGenerator, a corresponding "ghost object" would be created under the DocumentTemplateGenerator function.

Due to improvements in Plex's meta statements it is now possible to retrieve the necessary information without having to have the inheritance - so to get rid of the "ghost objects", this inheritance has been removed in this version.

This means that if you have made local modifications to functions inheriting from DocumentTemplateGenerator, you must check whether the changes still work.

There are three major issues to check - as these issues already have been handled in the abstract DocumentTemplateGenerator function, you only have to check your local modifications.

For two of the issues, you will see that the meta variable WSYBASE/+PageGenerator is used. The abstract DocumentTemplateGenerator sets this to the PageGenerator that scopes the DocumentTemplateGenerator. You can use this anywhere in the DocumentTemplateGenerator when you want a meta variable that refers to the PageGenerator.

Use of variables from the PageGenerator

One of the most common tasks of the DocumentTemplateGenerator functions is to process fields found in a local variable. As long as DocumentTemplateGenerator inherited from the PageGenerator, the variables were available in the DocumentTemplateGenerator and could be processed directly.

After removing the inheritance, the variables are no longer present in the DocumentTemplateGenerator - so the meta code processing the fields must be changed so that the variables of the PageGenerator are accessed.

Identifying whether you have the issue

If you have this issue, you will get error messages in the Plex message log when opening the DocumentTemplateGenerator function as variables that no longer exists in the function is referenced.

Examples

Note that the meta code shown in these examples can be used with any variables - not just WsyDetails and OmitDetailsFields.

The meta code:

+For Each Field WsyDetails

    ...meta code handling the fields in WsyDetails

Must be converted to:

+++Define Field: FIELDS/+Variable

+++Define Variable: WSYBASE/WsyDetails

+For Each Variable .Local, Field: WSYBASE/+PageGenerator

    +++Set Value To Current Field: FIELDS/+Variable

    +If EQ Field: FIELDS/+Variable, Variable: WSYBASE/WsyDetails

        +For Each Field

            ...meta code handling the fields in WsyDetails

In many cases you will find structures like this:

+For Each Field WsyDetails

    +++Undefine Field: WSYBASE/+FieldIsHidden

    +++Set Value To Current Field: WSYBASE/+FieldName

    +For Each Field OmitDetailsFields

        +++Set Value To Current Field: WSYBASE/+FieldName2

        +If EQ Field: WSYBASE/+FieldName, Field: WSYBASE/+FieldName2

            +++Define Field: WSYBASE/+FieldIsHidden

This meta code goes through all the fields in WsyDetails, for each field it is checked whether the field is in OmitDetailsFields - if it is, the meta variable +FieldIsHidden is defined.

This must be converted to:

+++Define Variable: WSYBASE/OmitDetailsFields

+++Define Variable: WSYBASE/WsyDetails

+++Define Field: FIELDS/+Variable

+For Each Variable .Local, Field: WSYBASE/+PageGenerator

    +++Set Value To Current Field: FIELDS/+Variable

    +If EQ Field: FIELDS/+Variable, Variable: WSYBASE/WsyDetails

        +For Each Field

            +++Undefine Field: WSYBASE/+FieldIsHidden

            +++Set Value To Current Field: WSYBASE/+FieldName

            +For Each Variable .Local, Field: WSYBASE/+PageGenerator

                +++Set Value To Current Field: FIELDS/+Variable

                +If EQ Field: FIELDS/+Variable, Variable: WSYBASE/OmitDetailsFields

                    +For Each Field    

                        +++Set Value To Current Field: WSYBASE/+FieldName2

                        +If EQ Field: WSYBASE/+FieldName, Field: WSYBASE/+FieldName2

                            +++Define Field: WSYBASE/+FieldIsHidden

If you look closely at this, you will see that this is just two separate cases of the previous example - first the conversion for WsyDetails is performed - then the conversion for OmitDetailsFields.

Retrieving options from the PageGenerator

When the DocumentTemplateGenerator inherited directly from the PageGenerator function, the inheritance meant that it could access the function options that were specified for the PageGenerator.

As the inheritance has been removed, the DocumentTemplateGenerator only has the options that have been set specifically for the DocumentTemplateGenerator (to override options from the page generator or as options that only relates to the DocumentTemplateGenerator).

If your code checks for function options that belong to the PageGenerator, you must enclose the code in a meta loop that specifies a meta variable that refers to the PageGenerator as the current object.

Identifying whether you have the issue

As the meta code doesn't generate any warnings if the options are missing, you must inspect your local modifications to the DocumentTemplateGenerator to check if any function options are retrieved from the PageGenerator.

You must check all "+For Each Property FNC option NME" statements.

Example

This code checks for the function option "Generate Start And End" - but the changes are the same for all options.

+++Define Field: WSYBASE/+GenerateStartAndEnd

+++Define Name: WSYBASE/Generate start and end

+++Define Field: FIELDS/+Name

+For Each Property FNC option NME

    +++Set Value To Current Field: FIELDS/+Name, .Target

    +If EQ Field: FIELDS/+Name, Name: WSYBASE/Generate start and end

        ...Handle function option

It must be changed to:

+++Define Field: WSYBASE/+GenerateStartAndEnd

+++Define Name: WSYBASE/Generate start and end

+++Define Field: FIELDS/+Name

+For Defined Value Field: WSYBASE/+PageGenerator

    +For Each Property FNC option NME

        +++Set Value To Current Field: FIELDS/+Name, .Target

        +If EQ Field: FIELDS/+Name, Name: WSYBASE/Generate start and end

            ...Handle function option

The addition of the +For Defined Value Field: WSYBASE/+PageGenerator statement ensures that the option is retrieved from the PageGenerator instead of from the DocumentTemplateGenerator.

Using fields that was defined on the PageGenerator

If you have made your own local modification to the DocumentTemplateGenerator functions, you might be using fields that have been added to the PageGenerator instead of to the DocumentTemplateGenerator.

The fix is simply to add the field to the variable specified in the error message. In rare cases the variable itself might be missing - you fix this by adding the variable to the DocumentTemplateGenerator followed by adding the fields to the variable.

Identifying whether you have the issue

You will receive an error message in the Plex log when opening the action diagram for the DocumentTemplateGenerator if you have this issue.

Websydian runtime upgraded to support MSXML 6.0

This information is only concerns the WinC (MSXML) version of TransacXML and Windows variants of WebsydianExpress

As of this version, Websydian TransacXML and WebsydianExpress will use the MSXML 6.0 parser instead of the MSXML 4.0 parser.

We change to MSXML 6.0 as this is a Microsoft recommendation - and because we see more and more servers where only MSXML 6.0 is installed.

This change will have no effect on your application and you do not have to regenerate/rebuild anything.

The change is done simply by replacing WsydXml11.dll with the one delivered as part of the upgrade objects for WebsydianExpress this is done by following the upgrade guides on how to upgrade to WebsydianExpress v3.0.4.

Before doing so, remember to check whether you have MSXML 6.0 installed.

You can do so by going to Control Panel→Add or remove programs, and check whether you find the MSXML 6.0 parser in the list.

Changes to Websydian Java Servlet runtime

This only concerns Java applications deployed as a servlet (the J2EEProxy feature).

Note that this means that it is relevant for the standard installation of WebsydianExpress for Java.

Two new options have been introduced for the j2eeProxy property file (Follow the link for further explanation of the properties).

1. servlet.plex.plexruntime.timeout
2. servlet.plex.plexruntime.maxpoolruntimes