Post Installation Settings
After the installation of the Ometa Framework is complete, there are still some settings you can tweak to get an even better performance and usability.
1. Core Web Service
Make sure the Core Web service is configured with the proper Framework BC Folder setting.
Please check the Core Framework Service - Framework BC Folder Configuration if you haven't done already.
2. Generic REST Settings
In framework versions before v5.4, all Generic REST settings were stored in the the appsettings.json configuration file. As this could pose security risks, all those settings are migrated to the Ometa Framework database starting from framework v5.4.
The migration step is done by the DbMigration after its data seeding. That migration process will read in the Generic REST settings from the appsettings.json file and copy them over to the corresponding database tables dbo.Config, config.SharePointAuthentications, config.SharePointRewriteUrls.
Note
The appsettings.json file is not modified. After the migration, the original settings will still be in the file but remain unused. This provides the opportunity to compare the original values to the ones in the database. It is safe to remove them from the appsettings.json file.
Important
Any already pre-existing values in the database will NOT be overwritten. Existing configuration is not modified and will have to be adapted manually in the database if necessary.
Consult the article Generic REST Service - Service Settings for more information.
3. BAM Windows Service
The BAM Windows service, BAM service for short, may need some configuration changes.
For a new installation of the framework the default settings match the old BAM method job settings as closely as possible.
Read the Configuration article for detailed settings information. A full description of all features can be found at BAM Service.
Note
Make sure that the BAM database connection string is provided or the service will fail to work.
Shared Settings
All settings of the BAM Windows service can be found in the general appsettings.json file, in the %OMETA_INSTALL_ROOT%\Ometa Software Suite directory.
In case of an upgrade, an appsettings.json file may be present in the %OMETA_INSTALL_ROOT%\Ometa Software Suite\Services\BAM WinService directory. We advice to move all settings from that file to the general appsettings.json file in %OMETA_INSTALL_ROOT%\Ometa Software Suite as that will make configuring the framework easier to manage. The BAM Windows service is equipped to search for the general settings file.
Any reference to SharedSettingsFiles can be removed.
4. Framework Settings
In this section you'll get an overview of all framework settings which can be fine-tuned.
In most scenario's the default settings are sufficient. However, take a look at the following settings because they might be relevant:
Follow the next steps to see the framework settings in the Ometa Business Connector:
- Start the Ometa Business Connector.
- Click on the blue application menu in the top left corner.
- Click on Settings.
- Click on Framework.
Architecture
The following architecture image gives you a better understanding of the internal working from a framework server.
- The Web API Server opens a socket via TCP 2005 to the BCM service.
- The BCM service opens a socket connection on TCP 2002 to the BCSL service.
- The BCSL service opens an internal connection to an interface, e.g.: BCS_SAP to retrieve data from SAP.
- The BCSL passes the connection of the BCM process to BCS_SAP (SAP interface). Communication is now directly between BCM and BCS_SAP.
- BCS_SAP executes the action on the SAP server.
BCA Service
The BCA or Business Connector Administration service is responsible for connection pooling and managing the work directory.
A larger buffer size potentially reduces the number of empty acknowledgements (TCP packets with no data portion), but might also delay the recognition of connection difficulties. Consider increasing the buffer size if you are using a high bandwidth or high latency connection (such as a satellite broadband provider).
In this case the default size is enough because messages sent to the BCA are always rather small. Changing this property requires a restart of the BCA service. The buffer size is expressed in bytes.
BCM Service
The BCM or Business Connector Manager service listens for incoming requests to the Ometa Framework.
- Port
- Buffer Size
- Enable Throttling Percentage
- Same Source Allowed Percentage In Throttling
- One Identical Source Allowed Percentage
- Working Directory
- Maximum Number Of Instances
- Maximum Queue Length
- SSL
- Maximum Cache Size
The port number of the BCM service. Changing this property requires a restart of the BCM service. It is not recommended to change the port number.
Interface Server
- Maximum Amount Of Interface Memory
- Maximum number of idle processes
- Idle Time Allowed
- Maximum Instances Settings
The maximum amount of memory in megabytes that an interface process may use. If the interface process is above this amount three method executions in a row, it will be terminated despite any other settings. This setting is also applied to already running interfaces within one minute.
Example: if you change this setting to 50 MB, existing interfaces with a memory consumption of 50 MB, will be killed after three method executions. Wait one minute to make sure the setting is applied to all running interfaces. The counter of three is reset when the memory consumption goes below the setting.
BCSP Service
Parallel Workers
The amount of threads the BCSP service can start when multiple actions should be performed by the BCSP service.
Configuration Table
A lot of options are configurable through the GUI, but eventually most of them end up in the configuration table.
This is a list of the most important settings in our configuration table.
| Key | Value Example | Description |
|---|---|---|
| Allowed Collection Fieldnames To Csv | identity.emails,case.roles,originatingcase.roles | Contains the names of the fields which will be serialized to a separate csv field. Names are comma separated. E.g.: identity.emails is a collection of email addresses. With this configuration in place, a new field named identity.emails.csv will be created with the collection values as a csv. Keep in mind that a new csv field will always be created, even if the field doesn't have a collection as value. |
| Authority Service Url | https://authority.ometa.net | The url of the Ometa Authority Service. |
| Core Service Url | https://core.ometa.net | The url of the Ometa Core Service. |
| Environment | Development | The environment of the installation. Valid values are Development, Testing, Acceptance & Production. |
| Generic REST Service Url | https://rest.ometa.net | The url of the Generic REST Service. |
| Repository Server | framework.ometa.net | The hostname of the framework server. |
5. Antivirus Exclusions
Antivirus software could potentially have a huge performance impact on the whole Ometa framework.
Ometa recommends to exclude atleast the following directories to ensure the framework does not encounter any delays:
- %OMETA_INSTALL_ROOT%\Ometa Software Suite\WorkDir
- %OMETA_INSTALL_ROOT%\Ometa Software Suite\TopDir\BC\Bin\Interfaces
- %OMETA_INSTALL_ROOT%\Ometa Software Suite\TopDir\BC\Profiles
- %OMETA_INSTALL_ROOT%\Ometa Software Suite\TopDir\BC\Objects
- %OMETA_INSTALL_ROOT%\Ometa Software Suite\Services\Ometa Generic REST Service\WorkDir
Optionally, exclude the log directories of BAM, Authority Service and Core Service.
- %OMETA_INSTALL_ROOT%\Log
6. Understanding IIS Recycling
IIS (Internet Information Services) recycling is a critical process for maintaining the stability and performance of web applications hosted on IIS servers. It involves restarting application pools within IIS, which helps manage memory usage, prevent memory leaks, and ensure optimal performance by refreshing worker processes.
Why IIS Recycling?
Over time, web applications running on IIS can consume increasing amounts of memory, leading to degraded performance and potential stability issues. IIS recycling addresses this by periodically restarting application pools, terminating existing worker processes, and starting new ones. This not only frees up memory but also ensures that resources are efficiently managed.
Scheduling IIS Recycling
It is crucial to schedule IIS recycling at a time when network traffic is minimal to minimize disruption. Typically, a fixed time such as 2:00 AM is recommended. Additionally, to stagger the downtime of each service, it's advisable to use different recycle times for each application pool. The interval between recycling actions can vary, but it's generally recommended to set it between 10 to 30 minutes. For example:
- Ometa Core Service: 2:00 AM
- Ometa Authority Service: 2:10 AM
- Ometa Generic REST Service: 2:15 AM
Fine-Tuning the Recycling Schedule
With proper monitoring, you can optimize the recycling schedule further. By monitoring the memory consumption of the W3WP worker processes daily, you can gauge when recycling is necessary. Once you have sufficient data, you can extend the recycle time to once a week and schedule recycling for the weekend.
It's recommended to check memory consumption every Friday before the weekend to ensure that it is not alarmingly high. This proactive approach helps maintain system stability and ensures optimal performance for your web applications hosted on IIS servers.
7. Health Reports & Telemetry
The Ometa Framework monitors the health of the installed Ometa software and its server. In case of any detected health issues, reports are created which can be automatically send to Ometa Hq (opt-in feature). We encourage to enable this so Ometa will know immediately if something unexpected/unhealthy is happening with the Ometa installation.
This is what you'll need to do to enable this feature.
Request a Telemetry Client
First, Ometa needs to register an entry on its Telemetry environment to be able to receive the reports. Consult your Ometa contact and request this Telemetry Client.
Database Configuration Table
The following configuration parameters must be set in the dbo.Config table.
By default, all these parameters are empty.
| Name | Description |
|---|---|
| Send Reports To Ometa Hq | Whether sending reports to Ometa is enabled. If anything but 'True' is configured, sending reports is disabled. |
| Ometa Hq Core Service Url | The url of the core service responsible for processing the reports. Defaults to https://telemetry-core.ometa.net if not filled in. |
| Ometa Hq Auth Service Url | The url of the authority service responsible for processing the telemetry client registration requests. Defaults to https://telemetry-auth.ometa.net if not filled in. |
| Report Client Id | The client id of the telemetry registration. You'll receive this information from your Ometa contact. |
| Report Client Secret | The client secret of the telemetry registration. You'll receive this information from your Ometa contact. |
| Anonymize Reports | Whether or not to anonymize the data in the report. If anything but 'False' is configured, reports are anonymized and will not contain sensitive or personal data. |
Important
Your firewall must be configured to allow HTTPS request to the 'Ometa Hq Core Service Url' and 'Ometa Hq Auth Service Url'.
Report Data
The following data is collected and send to Ometa (if enabled) when an health issue arises.
Current Method Executions
All methods which were executing at the time the report was created. This includes per method:
- Start Time
- Current Duration
- Object
- Method
- Profile
- Output
- If the report is not anonymized: all context data of the method execution
Important
The context of a method execution can contain sensitive data from your (ERP) systems and your users (e.g.: claims). Make sure this is allowed by your company policies before disabling anonymization.
Performance Data
A complete set of system variables which include:
- Hostname
- Processor Count
- Os Platform Information
- Physical Memory (Usage) Information
- Cpu (Usage) Information