General

There are three main types of changes to BlueWorx that ZAG will provide:

  • Support Packs - Support Packs (SP's) are cumulative so the first installed is effectively the customers base release. SP's contain all changes from previous SP's - i.e. you can skip SP's and apply a later one and it will contain all changes included in previous releases. These changes can be consequential in nature and, depending on the degree of change since last application update, can result in the following:
    • Review and change of affected processes and BlueWorx configuration options
    • Review and reapplication of Customer Enhancements
    • Full unit and end to end testing
    • Change Management communication with end users
    • Redeployment of the application to end users (for example if new Add Ins or Libraries are included)
  • Bug Fixes - Bug Fixes are specific to out of SP releases and must be applied as either a transport containing speficic cumulative fixes or instructions for the repair of standard ZAG (Soltius) SAP Classes/ Tables or Neptune Applications. On later application of SP's, which will contain cumulative bug fixes and new features, any changes can then be reset to to standard.
  • Manual Config - These are non code related changes which relate to changes to be made to BlueWorx config or BlueWorx related SAP config.

Details of these changes are provided in the section BlueWorx Releases (access restrictions apply).

Customer Enhancements and Impacts

Customers can maintain their own enhancements to the SAP back end logic via Classes and front end logic and visuals via the Neptune Application Designer. Such enhancements have a good degree of isolated from the Zag provided updates, meaning that BlueWorx updates will not overwrite the customers updates, however Zag initiated changes can impact on customer enhancements, the degree of impact depends on what has been changed. Zag will highlight in the release notes the changes and then the customer and partners should assess the appropriate impact and planning for implementation. 


As with any changes to standard software, Zag advocates good and proper review and control of changes, based on justifiable business reasons and with the understanding that any changes to standard creates technical debt. 

How the Process Works

Zag provides the standard product in cumulative support packs and, at internals, bug fixes. Customers can choose to apply bug fixes, if they are critical or wait for support packs. Regardless of the intent to change we strongly advocate (and detail further in our implementation guide) the use of Neptune enhancement applications linked to customer classes referencing the Zag provided class/es. Any changes made to standard are therefore isolated to these amended classes and, except for repairs, not to the source class. This keeps, as much as we are able, a clear understanding on what's been changed. 


The following diagram summarises how this process works:


Using this same concept, some BlueWorx customers choose to provide slightly different application versions to different user groups. For example one group of users might get simplified notification screens, no materials, etc, while another group gets to see everything.

Multiple Development Streams

If you have multiple BlueWorx development enhancement streams underway then you may wish to separate these so that your developers are working independently and so that they disrupt the core application as little as possible during the development process. Here is a concept of how to achieve this: