Ometa Framework Release v5.0.0
Below you can find important information regarding the 5.0.0 release of the Ometa Framework. As this is a major version, breaking changes might be applicable.
What's New
The most important features of the 5.0.0 are highlighted in the What's New.
Multi Threaded
The framework has become fully multi threaded which means that it has become more scalable than ever before. More transactions can pass over a single framework server with a reduced memory footprint.
In the images below there is a comparison made of a stress test between a 4.x and a 5.x release. A 4.x release has an average throughput of approx. 3 methods per second. A 5.x release has an average throughput of approx. 18 methods per second.
Caching
Every method in the framework can be cached. This is especially useful for master data methods or methods which can be slow to execute. When a cache entry is used throughout it's time period, the cache is automatically renewed. This can be boost the performance of a framework server giving an average throughput of approx. 37 methods per second.
Extensions
Data extensions can merge data over systems. This has been completly redesigned making more merge options available. Data extensions can now run in parallel to speed up the performance.
Smart Tiles
Smart tiles can be used to display KPIs from information systems and can be used for navigation purposes.
Document Approval
Ometa offers a generic document approval solution to work with SharePoint documents. This solution is build upon case management and tasks. The page and object views used for this approval are installed by default with the Ometa Framework.
BAM and Reporting
The Business Activity Monitoring has been redesigned to faster process all the logging gathered by the Ometa Framework. The cleaning mechanism of the BAM database has been significantly improved. Previously it could take multiple hours to perform the cleaning action of old entries. By the help of database partitions, thas has been reduced to minutes.
New BAM Reports are introduced for doing faster analysis on environments.
ADM Bundle Size
The bundle size of ADM is reduced with approx. 70%. It is also possible to define your own custom stylesheet.
Upgrade to v5.0.0
Before Installation
Local Group Policy
An extra requirements has been added to make sure that all Ometa Service Accounts for running Windows Services must have the Log on as a service access right.
An extra requirements has been added to make sure that all Application Pool Accounts must have the Log on as a batch job access right.
Refer to the accounts article for more information.
Upgrade .NET Core
Upgrade to the latest version of the .NET Core 3. Download and install the ASP.NET Core Runtime 3.1.28 Hosting Bundle.
Framework Services - SQL Server Database Access
As documented in the Minimal System Requirements - Framework Services, all framework services need access to the Case Management database.
This is especially important for the BCSL service in relation to the BaaN interface for which both are usually installed on a different host machine, containing the BaaN software. Make sure that the Case Management database can be accessed from that BaaN host machine or the BCSL service cannot start and renders using the BaaN interface impossible. See the BaaN Installation Requirements for more information.
Appsettings
Check all the appsettings.json since they are not overwritten by the setup if they already exists.
Root appsettings.json
- Go to the root
appsettings.json
file; by default:C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite
. - Create if not exisits.
- The default appsettings with a clean installation is the following, update the missing keys:
{
"BamConfig": {
"Enabled": true,
"Destination": "File",
"LogDirectory": "C:\\Program Files (x86)\\Ometa BVBA\\Log",
"PortalUrl": "http://bam:65487/Portal/Dashboard-Health.aspx",
"MaxPropertySize": 100,
"MinimumLogLevel": "Information",
"ProcessOverrides": []
},
"ConnectionStrings": {
"OmetaFrameworkDatabase": "Data Source=SQLSERVER;Database=OmetaFramework;Trusted_Connection=yes;",
"OmetaDcsDatabase": "Data Source=SQLSERVER;Database=OmetaDynamicCaseSystem;Trusted_Connection=yes;",
"OmetaBamDatabase": "Data Source=SQLSERVER;Database=OmetaBAMLogging;Trusted_Connection=yes;"
},
"FrameworkBCFolder": "C:\\Program Files (x86)\\Ometa BVBA\\Ometa Software Suite\\TopDir\\BC",
"LogProcessing": {
"OperatingMode": "Fixed",
"FileProcessing": {
"Enabled": true,
"IntervalTimeMinutes": 1
},
"Cleaning": {
"Enabled": true,
"CleaningTime": "01:00:00",
"DaysToKeep": 5,
"MaximumLogDataSizeGByte": 10.0
},
"Maintenance": {
"Enabled": false,
"MaintenanceDay": "Sunday",
"UpdateStats": false,
"UpdateIndexes": "None",
"DatabaseShrinking": false
}
}
}
Authority Service appsettings.json
Default location: C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite\Services\Authority Service
{
"AllowedHosts": "*",
"AllowedOrigins": [ "*" ],
"SigningCertificate": "CN=salesdemo.ometa.net",
"SharedSettingFiles": [
"..\\..\\appsettings.json"
]
}
BAM Service appsettings.json
Default location: C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite\Services\BAM Service
{
"SharedSettingFiles": [
"..\\..\\appsettings.json"
],
"ConnectionStrings": {
"CASEDBEntities": "metadata=res://*/CaseDBModel.csdl|res://*/CaseDBModel.ssdl|res://*/CaseDBModel.msl;provider=System.Data.SqlClient;provider connection string=\"data source=SQLSERVER;initial catalog=OmetaDynamicCaseSystem;persist security info=True;trusted_connection=yes;MultipleActiveResultSets=True;App=EntityFramework\""
}
}
BAM WinService appsettings.json
Default location: C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite\Services\BAM WinService
{
"SharedSettingFiles": [
"..\\..\\appsettings.json"
]
}
Core Service appsettings.json
Default location: C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite\Services\Core Service
{
"AllowedHosts": "*",
"AllowedOrigins": [ "*" ],
"SharedSettingFiles": [
"..\\..\\appsettings.json"
]
}
Generic REST Service appsettings.json
Default location: C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite\Services\Generic REST Service
{
"SharedSettingFiles": [
"..\\..\\appsettings.json"
],
"AppSettings": {
"EnableCompression": true,
"IsCloudEnvironment": true,
"SharePointAuthentications": [
{
"Source": "",
"IsCloudEnvironment": false,
"Domain": "",
"Username": "",
"Password": "",
"ClientId": "",
"ClientSecret": ""
},
],
"UseUnsafeUserContext": false,
"CoreServiceUrl": "https://core.service.net",
"AuthorityUrl": "https://auth.service.net",
"RedirectUrl": "",
"SilentRedirectUrl": "",
"Generic REST Service Communication Port": 50650
}
}
OPC UA Service appsettings.json
Default location: C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite\Services\OPC UA Service
{
"SharedSettingFiles": [
"..\\..\\appsettings.json"
],
"Pipeline Configuration": {
"BatchGroupingSize": 100,
"BatchPushInterval": 30
}
}
During Installation
Cannot Start OPC UA Service
If you install the OPC UA Module, the setup cannot start the OPC UA Service with an error in the event viewer.
- Go to the root
appsettings.json
file; by default:C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite
. Add the key
FrameworkBCFolder
on the root level which points to theBC
folder.{ "FrameworkBCFolder": "C:\\Program Files (x86)\\Ometa BVBA\\Ometa Software Suite\\TopDir\\BC", }
Cannot Start BAM Service
If you install BAM, it can happen that the BAM Service fails to start during the installation process. In the event viewer there is the following error:
Description: A .NET Core application failed.
Application: Ometa.Framework.Services.Bam.exe
Path: ...\Ometa BVBA\Ometa Software Suite\Services\BAM WinService\Ometa.Framework.Bam.exe
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet'.
- Click Cancel to rollback the installation process.
- Download and install the latest version of .NET Core 3.x (at the moment 3.1.28)
- Run the installation again.
After Installation
Remove Unnecessary Jobs
Remove the unused BAM Cleanup Job
and Ometa - Process BAM Files
method jobs.
- Open the Ometa Business Connector.
- Go to Method Jobs.
- Remove BAM Cleanup Job and Ometa - Process BAM Files.
Increase Max Instances
Increase the maximum instances to 200.
- Click on the blue application menu.
- Click on Settings --> Framework.
- Click on BCM Service.
- Increase the Maximum number of instances to 200.
Remove Log_Migrated
Remove the Log_Migrated table in the Ometa BAM Logging database if you do not need this logging any longer. Refer to the following article for more information.
Obiz Suite
The Obiz Suite needs to be added to the Core Service with the right appsettings. Refer to the following article for more information.
This new application will be used for standalone pages like:
- Closing and reassigning tasks.
- ...
Upgrade
Refer to the following articles:
Breaking Changes
As this is a major release, some breaking changes should be taken into account.
ADM Data Source Value
To ensure that the value of data source controls are what the user has inserted and are logical from a technical point of view. The value of data source controls is the value of all items and not just the valid items. This means that the value will change (and trigger value change events) on every item change. It is more intuitive that a control always has its value, and that on a higher level the control is deemed invalid when there are invalid values.
Edge
ADM has dropped support for the legacy version of Microsoft Edge and will stop working. Make sure that your Windows OS has the latest updates so you make use of the latest version of Microsoft Edge.
Case Aware Security
In version 4.4.0 we introduced a new property on a lifecycle to specify whether the memberships should be validated when requesting data from the web. To remain backwards compatible, this option was turned off by default. With version 5.0.0, validating the memberships will become the default. It will still be possible to turn the option off again for migration reasons.
Microsoft Provider
In version 4.4.0 we introduced a backwards compatible way for retrieving the AD groups of a user authenticating through the Microsoft provider.
The usage of AD groups is only useful when you have them under your own control (thus in your own Azure AD tenant). AD groups of external users are out of your control and might even conflict with the names of your own AD groups. Version 4.4.0 shipped with a backwards compatible scenario that would still retrieve AD groups of external users if no tenant id was specified but that changes in this major release:
- No tenant id specified: no AD groups will be retrieved for any user (even if they are inside your own organisation).
- Tenant id specified: behavior stays the same, AD groups will be retrieved for users within the specified tenant id.
This will force you to specify a tenant id, but also protects external organisations as less information is requested from them. Requiring less information will also make it easier for you to build a trust with external organisations you'd like to collaborate with.
Removal of Log Functions from CommLib
Due to a replacement of the underlying technology, from Microsoft Enterprise Logging to Serilog, to write log data directly to a database, some features initially provided by the Microsoft Enterprise Logging library are not available anymore.
These features were essentially only reserved for internal use by the Ometa framework but were publicly visible. In case a direct call or use of those features is applied in a custom DLL, some code changes and recompilation of the DLL will be needed.
The function WriteToDB
from the CommLib object Log is removed. The only way to use a direct write to the database, is
to set the Debug
flag in the BAM.config file to True
and use the normal Write
calls to create logging.
The Write
functions from the CommLib object Log do not support the use of a Microsoft Enterprise LogEvent object
anymore, as all types related to the Microsoft Enterprise Logging library are removed. The Write
functions now only support
the writing of strings. No workaround, apart from code changes, is available.
The "previous code" example below shows only one version of the Write
function, but the change applies to all overloaded
Write
functions.
Previous situation:
// Create a Dictionary of extended properties.
var properties = new Dictionary<string, object>();
properties.Add("Context Property", "Some Special Value");
// Create a LogEntry using the constructor parameters.
var logEntry = new LogEntry("Reporting important issue", "Verbose", 8, 9006, TraceEventType.Error, "Optional Title of Example", properties);
Log.Write(logEntry);
New code example:
Log.PropertiesHelper.Add("Context Property", "Some Special Value");
Log.Write("Reporting important issue", Log.Category.Verbose, 8, 9006, TraceEventType.Error, "Optional Title of Example");
BAM Portal Database Connection String
Due to changes on how the BAM database is accessed by the framework, the old connection string with the name BAMConnection is replaced by a connection string with the name OmetaBamDatabase.
Consult the article BAM Portal - Service Settings for more details.
BAM Logging Table Structure Change
In an effort to improve the performance of the BAM log file handling and BAM database maintenance/cleaning, the column structure of the Log table is changed, and the tables CategoryLog and Category are removed. Although this change is not considered are real breaking change as solutions or custom code should not read those tables directly but in case some might do anyway, note that reading the Log table directly will require modifications to handle the changed column structure.
During the migration process, any data already present in the Log table is preserved by storing that data in a separate table Log_Migrated but the category information is completely removed.
Important
Do not keep the table Log_Migrated forever. When enabling the cleaning to size task, more data might get removed that anticipated because the presence of the Log_Migrated table may skew any size calculations. Check the contents and drop the table as soon as possible.
BAM Report 'Logging By Message And Title' Replaced by 'Logging By Message And Component'
The log field Title
is replaced by a field called Component
and this impacts the Ometa.BAM.LogAnalysis object. More specifically, the method Get Logging By Message And Title
and corresponding report is replaced by Get Logging By Message And Component
.
Additionally, the input field Report Logging By Message And Title on the method Export Reports To File
is replaced by Report Logging By Message And Component
.
When those methods are used in a solution (directly or through method jobs), adapt the references and setting of context fields to make sure the new versions are called.
BAM Logging in Custom Code
In preparation for multi-tenancy support for the framework, custom code using BAM logging must have an appsettings.json with connection strings for the Ometa databases. This applies only to applications that are not placed within the Ometa installation folder (default C:\Program Files (x86)\Ometa BVBA\Ometa Software Suite
). For example:
- Custom migration tools
- Custom sites or services
- Development tools to test DLL's
Note
Custom DLL's placed in the BCS_DLL 4 interface folder and executed by the framework will use the framework settings and do not require any changes.
You can recognize this issue as a warning in the eventlog with message Initializing the Ometa Business Activity Monitoring system failed
. In the body of the warning, there is no Config file location
, no Log directory location
and no appsettings available.
In order to resolve this, add an appsettings.json file in your custom application that refers to another shared service settings file, or contains the connection strings:
Shared Service Settings File (Recommended):
Use a shared service settings to link to the appsettings of the framework. This ensures that the settings will always be in sync with the rest of the Ometa framework.
{ "SharedSettingFiles": [ "C:\\Program Files (x86)\\Ometa BVBA\\Ometa Software Suite\\Services\\Core Service\\appsettings.json" ] }
Json
Alternatively, the plain json configuration can be placed in the appsettings.json file.
{ "ConnectionStrings": { "OmetaFrameworkDatabase": "Data Source=dbserver.ometa.net;database=framework database;trusted_connection=yes;", "OmetaDcsDatabase": "Data Source=dbserver.ometa.net;database=dcs database;trusted_connection=yes;", "OmetaBAMDatabase": "Data Source=dbserver.ometa.net;database=bam database;trusted_connection=yes;" } }
Possible OPC UA Data Conversion Issues
The way how the framework OPC UA Windows service and interface convert data between the OPC UA server and the framework itself has changed. In many cases it will work fine but for some attribute - field types there could be some breaking issues.
For example: OPC UA Byte
fields will have a different output representation at the moment of conversion into a framework Text field, when read by the v5 framework version than it would have been by the older v4.x framework versions.
In v4.x, OPC UA fields were converted using simple .NET conversions without much type checking. In the case of Byte
fields, values were converted into numeric values and then assigned to the framework Text field. However, with the current framework version v5, Byte
s are first converted into hexadecimal strings when assigned to Text fields. To get the same numeric value as before, it is necessary to change the field types in the framework object/method to either Number or Integer.
For more detailed information about how OPC UA data is handled by the framework now, consult the article OPC UA Support Data Type.
Usage of System Profile for Custom Code
Using one of the Ometa system DLL4
profiles for custom code can cause concurrency issues. Validate if one of the following profiles are used for custom made DLL4
methods:
- Data Utilities
- DCS Utilities
- DLL Document Approval
- Mail Building Block
- SharePoint Building Blocks
- Teams Building Blocks
Note
This is only breaking for custom code. The system methods and views like Ometa BuildingBlocks, or DCS.System object are not an issue.
The BAM
profile remains backwards compatible, no change is required for methods using this profile.
In this version, the interface processes have become multi-threaded. This means that only one DLL4
process will be active at a time, capable of processing multiple requests at a time. To benefit from this, the system profiles above have been configured to use Isolation : Default
. Custom code is not migrated and will throw runtime errors.
The options to resolve this are:
- Migrate custom code to support multi-threading, refer to the dll migration guide for more information.
- Copy the system profile, and configure
Isolation : Dedicated
on it. Use this profile for custom code that is not yet migrated. - Temporarily set the profile to
Isolation : Dedicated
. This isn't optimal as it increases memory usage and doesn't take advantages of the optimizations in system methods.
Increased Maximum Interface Memory Setting
The default maximum interface memory usage has been increased from 500 to 1000 due to processes serving multiple requests at a time. If a different value is configured, consider increasing this. A low maximum interface memory setting impacts how often the interface process is restarted. This can have a performance impact for the method starting a new process too often.
Multi Record View For Inline Editing
Note
This is only breaking for ADM3 configurations, Kendo configurations will remain unchanged.
The option to specify a multi record view that will be used by the update view when inline editing is used with the update view will be ignored (not removed because this is still used in Kendo). This will result in a performance boost and will make configuration easier.
The configuration of inline editing is simplified. You used to configure a multi record with update enabled. The update view had to have a multi record view for inline editing configured. Now you enable the update view on the multi record and that is it.
This means that you can not specify different multi records to use in inline edit mode. The original multi record will be used to retrieve the data to use in inline edit mode. Make sure that the original multi record has at least the fields that are used in the update view to ensure correct behavior. To learn more about this, check out the inline editing article about the field configuration.
To learn more about configuring inline editing, check out the inline editing article.
Framework Config Table
The config table with the framework configuration has been moved from the Ometa Framework database, to the Ometa Dynamic Case System database. Configuration is automatically ported over upon running the installer. However if you relied on the table in any methods, or other custom applications that use this table, they must be changed to target the table in the Ometa Dynamic Case System database instead.
This table still exists with a placeholder entry, but will be removed in a future release.
Default Input and Input Choice List Validation
When saving changes to object and method fields, an extra check is added to make sure that the default input value of that field is present within the input choice list. If that is not the case, the save action will fail and an exception is thrown.
This validation cannot be skipped and is applicable to both the saving of object and method fields within the WpfGUI, as doing such save actions in custom DLL's.
Data Extensions
The data extensions have been migrated from xml to our core databases. This migration happens when executing the patcher and when the BCM is started the first time.
When the migration of an object is successful, it will receive a new patch version attribute in its xml with the current patch version. When an object already has the latest patch version, it will not be processed by the patch service anymore.
If anything fails when patching an object, you'll find the details of that error in the BAM reporting and optionally in the event viewer. After such a failure, it can happen that your object cannot be used by the new version of the framework (depends on the type of error). Please correct the error(s) in your object xml and retry to patch it by restarting the BCM. A backup of your original object xml can always be found in the {OmetaInstallDir}\TopDir\BC\Bin\Patch\{CurrentVersion} directory.
Important
When migrating the data extensions in an object xml, invalid data extensions (e.g.: when an extension object, method or field cannot be found) will be removed from your object. If this happens, your object will still be migrated successfully, but an error will be written to the BAM log. The object won't contain that data extension anymore.
Please consult BAM after migrating your objects to see if anything failed and make sure you consulted (and optionally corrected) those errors before considering the migration successful.
Copying Object Xml's
Warning
It is still common practise to copy and paste object xml's through the DTAP street. However due to the changes regarding data extensions, you will no longer be able to just copy paste an object xml with its data extensions. Those extensions are no longer contained in the xml and you will lose that configuration once the object is pasted in another server.
Use the transfer tool to correctly export and import objects and/or methods.
Coding with Data Extensions
Due to the fact that data extension have been moved to the core layers, existing code which targets data extensions will possibly break.
The following symbols have been removed:
- Method.DataExtensions
- Method.InputDataExtensions
- Method.OutputDataExtensions
- Method.AllDataExtensions
- Method.AddDataExtension(bool input)
- Method.RemoveDataExtension(DataExtension extension)
- Method.GetDataExtension(bool input, string dataExtensionObject, string dataExtensionMethod)
- Class BC.Extensions.DataExtension (CommLib)
- Class BC.Extensions.FieldRelation (CommLib)
var myObject = bcClient.GetObject("MyObject");
var myMethod = myObject.GetMethod("MyMethod");
// Usage of any of the following lines will break your code (compilation error):
var dataExtensions = myMethod.DataExtensions;
var inputDataExtensions = myMethod.InputDataExtensions;
var outputDataExtensions = myMethod.OutputDataExtensions;
var allDataExtensions = myMethod.AllDataExtensions;
var newDataExtension = myMethod.AddDataExtension(true);
var myDataExtension = myMethod.GetDataExtension(true, "MyExtensionObject", "MyExtensionMethod");
myMethod.RemoveDataExtension(myDataExtension);
DataExtension myDataExtensionInAVariable = null;
FieldRelation myFieldRelationInAVariable = null;
In most cases, the only code that should be fixed is the one which is responsible for setting data extension profiles on a method which is going to be executed.
The following example shows how to change your existing code.
var myObject = bcClient.GetObject("MyObject");
var myMethod = myObject.GetMethod("MyMethod");
// Your original code could look like this (and will now break compilation):
foreach (var aDataExtension in myMethod.DataExtensions)
{
myMethod.SetDataExtensionProfileForExecution(aDataExtension.Id, "myProfile");
}
// The above code can be replaced by:
foreach (var aDataExtensionSetting in myMethod.DataExtensionSettings)
{
myMethod.SetDataExtensionProfileForExecution(aDataExtensionSetting.Identifier, "myProfile");
}
The new DataExtensionSetting class is contained in our new Ometa.Framework.Client API (which will eventually replace the whole Ometa.CommLib and Ometa.Dcs libraries). The new property Method.DataExtensionSettings uses this class so existing code can be migrated with as little effort as possible.
If you, however, have code in place which also manages data extensions through the old Ometa.CommLib data extension class, let us know so we can help migrate your codebase.
Base64 Maximum File Size
The max file size that can be uploaded using base64 is now limited to 1 Gigabyte, this is done to prevent browser crashes and memory problems.
Use Separate View On Single Record
The option on multi record views Use Separate View On Single Record will no longer be supported on ADM. This option can still be configured for Kendo ADM and will be removed after 1 October 2023.
This is no longer supported because this provides a bad user experience for end users.
Deprecations
Kendo ADM
Kendo ADM uses AngularJS technology. This technology is deprecated starting from 31 December 2021. This is why Ometa announce to drop the support on Kendo ADM with immediate effect.
Kendo ADM will be removed after 1 October 2023. Ometa will still offer support when there are critical or blocking issues.
Ometa recommends to migrate to the latest version of ADM.
SharePoint 2013
Ometa will stop supporting SharePoint 2013 starting from 4 November 2023.. It is recommended to migrate to the latest version of SharePoint Server before this date.
Interface properties in custom coding
This impacts custom code written for use by the DLL 4 interface.
The following static properties and functions on Ometa.Interfaces.Interface
have been made deprecated:
- ConnectedClient
- Method
- IsViaSynchronisationJob
- Profile
- ResultWriter
- IncludeAllDocuments
- DocumentChecksumsToInclude
- QueryOptions
- Log
- GetProfileVariable
- TryGetProfileVariable
- ProcessContextRecordErrorOrRethrow
Code using these properties must be migrated to implement IRequestProcessor
which provides these properties itself.
These properties may still be used when the profile uses Isolation : Dedicated
. In version 6.0.0, these properties will be removed.
Visit the dll migration guide for more information.
Ometa BuildingBlocks Namespace
This only impacts custom code that used functionality from the Ometa BuildingBlocks in code.
The buildingblocks have been moved to Ometa.Framework.BuildingBlocks
from Ometa.Utilities.Client
. The methods in the old namespace will show a warning to migrate to the new namespace, but will still work if Isolation : Dedicated
is configured in the profile.
Visit the dll migration guide for more information.
Ometa Core Service
The odata/cases/getcaseswithrelations
endpoint on the Ometa Core Service is deprecated since 5.0.0 and will be removed in version 6.0.0.
Ometa OPC UA Service Subscriptions
Internally the OPC UA service subscriptions store everything in database tables for correct retrieval of the subscription definitions. The table Subscriptions
contains 3 columns: ProfileName, ObjectName and MethodName. These columns are replaced by the column MethodSettingsId which refers to the same information
in a different table.
As those columns are not needed anymore, they are deprecated starting version 5.0.0 and will be removed in version 6.0.0. The internal fields on SubscriptionDefinition
and TransferSubscription
will also be removed.
Tasks
The 'DCS.Tasks' object is reworked. The old 'DCS.Tasks' object is still available as 'DCS.Tasks - Deprecated'. The current views that use this object will need to be updated accordingly.
Virtual Methods and Virtual Fields
Virtual methods and virtual fields have been unsupported for a while and are now removed from the framework. If any configuration was yet to be migrated, the original xml file can be recovered from the Patch folder: Ometa BVBA\Ometa Software Suite\TopDir\BC\Bin\Patch\[version]\Objects\
.
Case Property Context
Context With 'caseproperty.' prefix
To prevent conflicts with case properties and other context fields, the case property fields starting with the prefix 'caseproperty.' are deprecated. You'll have to use the prefix 'case.properties.' or 'originatingcase.properties.' to target (originating) case properties. Starting from v7.0.0, the fields starting with the prefix 'caseproperty.' will no longer be added to the context of a method.
Caseid Context Field
The context field named 'Caseid' is deprecated. Starting from v7.0.0, this field will no longer be automatically added to the context of a method.
Breaking Changes
Data Source Value
To ensure that the value of data source controls are what the user has inserted and are logical from a technical standpoint. The value of data source controls is the value of all items and not just the valid items. This means that the value will change (and trigger value change events) on every item change. It is more intuitive that a control always has its value, and that on a higher level the control is deemed invalid when there are invalid values.
Changed Functionality
Notifications
The notifications used to be shown on the ADM. This lead to some visual struggles because the whole page jumps when a notification is added or removed.
To counter this, the notifications are moved to toast messages. This means that the message is shown in the top right corner of the screen. When clicking on a toast message, the component that triggered the toast will be highlighted.
Realtime ADM: Changed Behaviour
The following will be changed in realtime ADM.
When a multi record is dirty, no realtime notifications will be processed. The user will only see a notification that there were changes. The multi record view will be considered as dirty when the user:
- filters the data;
- sorts the data;
- makes a selection of rows;
- executes list item functions.
In this notification, the user has the possibility to retrieve the changes. The user will visually see what has been changed when processing the changes.
When a new record has been added, the user will always see a notification. It is no longer possible to get this new change real time.
CSL Pointers
Standard variables like the ones below will be removed from the different scripts in version 7.0.0 and existing scripts will be updated with an interactive patcher.
const htmlElement = CSL.htmlElement();
const viewConfig = CSL.viewConfig();
The following scripts will be changed:
- configuration script
- view event script (OnLoadComplete, BeforeSave, AfterSave, ...)
- view field event script (ValueChanged, OnBlur, OnChanged, ...)
- function event script (BeforeExecute, AfterExecuteAlways, ...)
Note
The names of these CSL pointers are still under review and can be changed in the final version.
Until then these will still be in configuration scripts but it's a good practice to already use the CSL pointers yourself and not rely on these standard variables. This means that when you want to use the 'htmlElement' you'll have to use the code below to access it.
CSL.htmlElement();
Validation Parameters
The validation event contains a number of parameters that can do more harm than good. To protect the configurator from doing any harm, some validation parameters will be removed.
The validation events will remove following parameters:
- validationOptions
- These options contained all the settings to execute the validation. The content of these options are not useful for a configurator. If these options are altered, unexpected behavior will occur.
- form
- The complete form was passed. Properties of the form can be accessed by CSL functions. Altering anything on this form will occur in unexpected behavior.
- viewField
- The complete configuration of the view field that is being validated doesn't contain any useful information.
- viewFields
- The complete configuration of all the view fields configured on the view. This information doesn't provide any useful information in this event.
Date Picker
Since the upgrade to Angular 14, when going into a date picker control, the date picker will be opened automatically with the difference that the date picker is focused instead of the text input control.