3 Release Installation
In this chapter, the generic process for Installing an OHI Product Definition release is described. Release specific instructions are documented in the Release Notes for that specific release.
3.1 Install database objects
3.1.1 Change Installation Configuration
-
In <OHI_ROOT>\util\install, make a copy of ohi_install.cfg.template and name it ohi_install.cfg.
-
Edit ohi_install.cfg to contain your specific database connection data and other configuration settings. The settings are explained in the file itself.
By default, the schema passwords will be similar to the schema user names. The ohi_install.cfg files allows the specification of different passwords. Alternatively, specify empty string passwords to have the option of entering the passwords at the command prompt. In the latter case, the passwords will not end up in a configuration file.
The tablespaces mentioned in the ohi_install.cfg should exist, prior to running the installation.
Default schema passwords should not be used.
Oracle recommends that schema passwords are entered at the command prompt. Never store passwords in configuration files.
3.1.1.1 Configure Instance Discriminator
In accordance with the concepts explained in the paragraph Enabling Replication of Setup Data, the correct environment or instance must be configured during a new installation. The data that is entered for ohiInstances in the ohi_install.cfg file is stored in the database when a fresh install is performed. Make sure to assign unique discriminator values for each environment.
3.1.2 Run Installer
-
Open a command window and browse to <OHI_ROOT>\util\install.
-
Depending on the O/S you should run ohi_install.bat (Windows) or ohi_install.sh (Linux). This will assume that the config file ohi_install.cfg is present in the same directory where ohi_install.bat is present and uses the default configuration from ohi_install.cfg. To specify a different location of ohi_install.cfg or to specify a different environment from ohi_install.cfg, follow the next step.
-
Specify the command line options to specify the location of ohi_install.cfg file and environment to use from ohi_install.cfg.
-
-
Eg: ohi_install.sh -c /home/oracle/someLocation/ohi_install.cfg -e dev
-
-
The command line arguments are explained below:
| Option | Arguments | Description |
|---|---|---|
| Short Long | ||
| -c --cfg | config file path | The location of the configuration file. Default is ohi_install.cfg |
| -e --env | environment names | The name that specifies which of the environment settings from the config file to use |
3.1.2.1 Install Seed Data
Part of the database objects installation is the installation off Seed Data.
3.1.2.1.1 Generic Seed Data
Seed data is maintained by Oracle. Customers should not change this data except the updatable columns. It is delivered as part of a release and may be updated by software upgrades.
3.1.2.1.2 Localization Seed Data
This category covers specific data that is required by localizations. The data is maintained by Oracle. Customers should not change this data. It is delivered as part of a release and may be updated by software upgrades.
3.1.2.1.3 Sample Data
Sample data is provided by Oracle to give you a headstart during configuration. This is data configured by Implementation Consultants. It is not modified during future upgrades. For more information, see Appendix B - Seed Data
3.1.2.1.4 Restrictions on using Seed Data
Because Seed Data is maintained by Oracle, it may be modified or even deleted as part of an upgrade. Customers should therefore exercise caution when using seed data in their configuration by abiding these rules.
-
Do not remove (delete) Seed Data rows. A patch may re-insert the row.
-
Do not update columns, other than those indicated as updateble below.
-
Do not make references to rows that may be deleted by Oracle (see table below).
Violations of the rules above (especially rule 3) may lead to failures during the installation of upgrades.
The table below lists the Seed Data tables.
-
Data: The table or logical entity
-
Updateable columns: The customer may update the values in these columns. They will not be overwritten by upgrade scripts. Other columns should not be updated by the customer.
-
Physical Delete: Upgrade scripts may delete this data. The customer should not create references to this data.
| Data | Updateable Columns | Physical Delete | Remarks |
|---|---|---|---|
| Access Restrictions | Yes | Also deletes Access Restriction Grants referring to this row | |
| Access Restriction Grants | Yes | ||
| Access Roles | ind_enabled | No | Two roles are seeded |
| Boilerplate Texts | Yes | ||
| Country Regions | No | ||
| Data set definitions | Yes | ||
| Dynamic Field Usages | No | ||
| Dynamic Logic | No | ||
| Fields (+ dynamic logic) | No | ||
| Flex Codes | No | ||
| Flex Code Sets (+ details) | No | ||
| Flex Code Systems | No | ||
| Languages | ind_default ind_installed | No | |
| Messages | ind_suppress_log_in_ui ind_suppress_log_in_ext ind_mark external_code | Yes | |
| Single Flex Code Definitions (+ usage) | No | ||
| Task Types | Yes | Customer is not allowed to change anything in base table | |
| Task Type Attributes | value_char value_number value_datetime value_clob | Yes | |
| Users | No | One User will be seeded (system user) |
3.1.2.2 Enable Total Recall (optional)
When Total Recall Option is activated, you should decide if one or more of the new tables should be added to a Flashback Data Archive.
Syntax to enable history tracking for a table is:
ALTER TABLE <tablename> FLASHBACK ARCHIVE [<Flashback Data Archive name>];
Note that the FDA name is required only when adding the table to a non-default FDA.
To disable history tracking for a table use:
ALTER TABLE <tablename> NO FLASHBACK ARCHIVE;
3.2 Install Application
This section lists the steps that are required to install the OHI application on the Oracle Fusion Middleware WebLogic Server (WLS).
3.2.1 Creating WebLogic Work Managers
By default, WebLogic Server uses the default work manager to handle thread management and perform self-tuning. This default Work Manager is used by an application when no other Work Managers are specified in the application's deployment descriptors. For more information, check the WLS documentation: http://docs.oracle.com/cd/E17904_01/web.1111/e13701/self_tuned.htm.
However, it is recommended to use the following application-specific work managers:
-
a work manager to control UI requests, named "wm/ui-work-manager"
-
a work manager to control Web Services requests, named "wm/ws-work-manager"
-
and a work manager to control task processing (like File Import batch processing), named "wm/core-work-manager"
This allows more fine-grained control and work load monitoring of the system.
These work managers are configured by the WLST scripts as part of creating a new domain. For an existing domain the work managers need to be configured manually. If these work managers are not configured, the system issues warnings at startup like the following example and will use the WLS default work manager instead:<Warning> <WorkManager> <BEA-002919> <Unable to find a WorkManager with name wm/core-work-manager. Dispatch policy wm/core-work-manager will map to the default WorkManager for the application.
Create global work managers through the Administration Console using the steps that are listed in the following table in the given order. Make sure to associate the work managers with the managed servers.
| Step | Configuration | Value |
|---|---|---|
| 1 | Minimum Threads Constraint | |
| Name | core-work-manager-min-threads-constraint | |
| Count | 16 | |
| 2 | Maximum Threads Constraint | |
| Name | core-work-manager-max-threads-constraint | |
| Count | 16 | |
| 3 | Fair Share Request Class | |
| Name | core-work-manager-fair-share-req-class | |
| fair Share | 40 | |
| 4 | Work Manager | |
| Name | wm/core-work-manager | |
| Request Class | core-work-manager-fair-share-req-class | |
| Minimum Threads Constraint | core-work-manager-min-threads-constraint | |
| Maximum Threads Constraint | core-work-manager-max-threads-constraint | |
| Capacity Constrain | None Configured | |
| Ignore Stuck Threads | Checked | |
| 5 | Minimum Threads Constraint | |
| Name | ws-work-manager-min-threads-constraint | |
| Count | 10 | |
| 6 | Maximum Threads Constraint | |
| Name | ws-work-manager-max-threads-constraint | |
| Count | 100 | |
| 7 | Fair Share Request Class | |
| Name | ws-work-manager-fair-share-req-class | |
| Fair Share | 50 | |
| 8 | Work Manager | |
| Name | wm/ws-work-manager | |
| Request Class | ws-work-manager-fair-share-req-class | |
| Minimum Threads Constraint | ws-work-manager-min-threads-constraint | |
| Maximum Threads Constraint | ws-work-manager-max-threads-constraint | |
| Capacity Constraint | None Configure | |
| Ignore Stuck Threads | Checked | |
| 9 | Minimum Threads Constraint | |
| Name | ui-work-manager-min-threads-constraint | |
| Count | 5 | |
| 10 | Maximum Threads Constraint | |
| Name | ui-work-manager-max-threads-constraint | |
| Count | 100 | |
| 11 | Fair Share Request Class | |
| Name | ui-work-manager-fair-share-req-class | |
| Fair Share | 50 | |
| 12 | Work Manager | |
| Name | wm/ui-work-manager | |
| Request Class | ui-work-manager-fair-share-req-class | |
| Minimum Threads Constraint | ui-work-manager-min-threads-constraint | |
| Maximum Threads Constraint | ui-work-manager-max-threads-constraint | |
| Capacity Constraint | None Configured | |
| Ignore Stuck Threads | Checked |
After configuring the work managers, managed servers need to be restarted.
The work manager configuration, like the minimum and maximum threads constraints and the fair share request factors, can be modified at any time in WLS Admin Console as is required, for example to increase the number of threads used for task processing.
This largely depends on hardware capacity, system configuration and the load characteristics and typically requires a thorough understanding of the system's performance.
3.2.2 Configuring OID Authentication Provider
The application uses a WebLogic Authentication Provider to connect to Oracle Internet Directory (OID) or to a third party LDAP server. This section describes the configuration of an OID or third party LDAP Authentication Provider.
Alternatively, for creating a new WebLogic domain for OHI Product Definition use the WLST scripts for setting up the Authentication Provider.
Step 1: Login to WLS admin console and click on Security Realms link.
Step 2: Click on myrealm link.
In WLS Production-mode use the Lock & Edit button before clicking on the New button.
Step 3: Click on Providers tab.
Step 4: Click on New button.
Step 5: Change Name and Type to OHIProdDefAuthenticationProvider and OracleInternetDirectoryAuthenticator (or to LDAPAuthenticator in case a third party LDAP server is used) respectively in Create a new Authentication Provider page. Click on OK button.
Step 6: Click on OHIProdDefAuthenticationProvider link.
Step 7: Change the Control Flag to SUFFICIENT and click on Save button.
Step 8: Click on Provider Specific tab.
Step 9: Enter/change the values for various fields as shown below and select the option Propagate Cause For Login Exception. Click on Save button.
| Field | Value |
|---|---|
| Host | LDAP hostname or IP address |
| Port | LDAP Port or SSL Port if the LDAP is SSL enabled. E.g.: 3060. In case LDAPS is used, make sure to check the SSLEnabled flag as well. |
| Principal | LDAP admin principal: E.g.: cn=orcladmin |
| Credential | LDAP admin password |
| Confirm Credential | LDAP admin password |
| User Base DN | User Base distinguished name. E.g.: ou=Users,dc=healthinsurance,dc=oracle,dc=com |
| All Users Filter | E.g.: (&(uid=*)(objectclass=person)) |
| User From Name Filter | E.g.: (&(uid=%u)(objectclass=person)) |
| User Name Attribute | E.g.: uid |
| Group Base DN | If there are no groups in the LDAP, leave this field empty. |
There are a few more properties (or fields in the page) which are not mentioned in the table above. Change the values of those fields to suit your LDAP settings.
Step 10: Click on myrealm link and then DefaultAuthenticator link. Change the Control Flag to SUFFICIENT and click on Save button.
Step 11: Restart the WebLogic Server.
Optionally, verify that the authentication provider is configured successfully (after the WebLogic Server is restarted) by following the steps mentioned below:
Step 1: Login to WLS Admin Console and click on Security Realms
Step 2: Click on myrealm
Step 3: Click on Users and Groups tab
Step 4: You should be able to see the list of users from OHIProdDefAuthenticationProvider (in addition to the default users from DefaultAuthenticator).
3.2.3 Set up JDBC Data Sources
The application connects to the Oracle database through a Data Source that need to be specified in the WLS Server.
For security reasons, the database connections used by the application connect to database schemas that do not own database objects. These schemas are only granted the required privileges to use the objects.
The following sections describe setting up data sources for connecting to:
-
an Oracle database that is running on a single machine
-
a RAC-enabled Oracle database that is running on multiple machines
3.2.3.1 Data Source for connecting to an Oracle database that is running on a single machine
The following table lists the Data Source that must be configured in WLS before installing the application for use with an Oracle database that is executed on a single machine (not clustered):
| Data Source Parameters | Non-clustered database | Explanation |
|---|---|---|
| Data Source Name | ohi-application-datasource | Logical name |
| JNDI Name | jdbc/proddefUserOhiApplicationDS | Used by the application to resolve the Data Source |
| Database Type | Oracle | |
| Database Driver | Oracle's Driver (Thin) for Instance connections; Versions:9.0.1,9.2.0,10,11 or
Oracle's Driver (Thin) for Service connections; Versions:9.0.1,9.2.0,10,11 |
|
| Database Name | SID or service name of the database
If the name of the Oracle driver that was selected contains the words "for Instance connections" enter the SID. If the name of the Oracle driver contains the words "for Service connections" enter the service name. |
|
| Host Name | Name or IP address of the machine where the database is running | |
| Port | Port on which the database is running | |
| Database User Name | ohi_proddef_user | Fixed value, do not change |
| Password & Confirm Password | Password of "ohi_proddef_user" | The schema password as selected during the installation |
The data sources can be created by either
-
using the <OHI_ROOT>\util\wlst\createOHIDomain.sh script (i.e. the data sources are created at the time the domain is created) or
-
creating them through WLS Admin Server console (see sample below).
3.2.3.2 Data Source for connecting to an Oracle RAC database that is running on multiple machines
To support Oracle RAC features within Oracle WebLogic Server, Oracle recommends using Oracle WebLogic Server GridLink Data Source. A single GridLink data source provides connectivity between WebLogic Server and an Oracle Database service targeted to an Oracle RAC cluster. It uses the Oracle Notification Service (ONS) to adaptively respond to state changes in an Oracle RAC instance. An Oracle Database service represents a workload with common attributes that enables administrators to manage the workload as a single entity.
To configure this, the following steps need to be performed. For more details about GridLink Data Source configration, see the Oracle WebLogic Server documentation: http://download.oracle.com/docs/cd/E17904_01/web.1111/e13737/gridlink_datasources.htm.
3.2.3.2.1 Configuring GridLink Data Source
Step 1: Login to WLS admin console and click the Services/Data Sources link.
Step 2: Click on New button and select the option GridLink Data Source
In WLS Production-mode use the Lock & Edit button before clicking on the New button.
Step 3: Change the value of Name to ohi-application-datasource and enter jdbc/proddefUserOhiApplicationDS in JNDI Name. Click the Next button.
Step 4: In Transaction Options page, accept the default settings (Supports Global Transactions and One-Phase Commit) and click the Next button.
Step 5: If SCAN (Single Client Access Name) is used for the Oracle RAC database, select the option Enter complete JDBC URL. Else, select the option Enter individual listener information.
Step 6: In Connection Properties page either
-
enter the values of various fields as outlined in the table below if option Enter complete JDBC URL is selected:
Parameters Value Explanation Complete JDBC URL jdbc:oracle:thin:@{scan-listener-host}:{scan-listener-port}/{service-name} JDBC URL using SCAN Database User Name ohi_proddef_user Fixed value, do not change Password & Confirm Password Password of "ohi_proddef_user" The schema password as selected during the installation -
or enter the values of various fields as outlined in the table below if option Enter individual listener information is selected:
Parameters Value Explanation Service Name Oracle RAC service name Host and Port hostname1:port hostname2:port
Individual RAC node details. The format is <HOSTNAME>:<PORT> Database User Name ohi_proddef_user Fixed value, do not change Password & Confirm Password Password of "ohi_proddef_user" The schema password as selected during the installation
Step 7: In Test GridLink Database Connection page, click on Test All Listeners to see if the connection is successful. Once the test connection succeeds, click on Next button.
Step 8: Enter the details of ONS client configuration as outlined in the table below and click the Next button.
| Parameters | Value | Explanation |
|---|---|---|
| Fan Enabled | Check-box selected | Enables the data source to subscribe to and process Oracle FAN events. This attribute is only applicable for RAC configurations that publish FAN notification events using the ONS protocol. |
| ONS Nodes | Eg: hostname1:6200,hostname2:6200 | A comma-separated list of ONS daemon listen addresses and ports to connect to for receiving ONS-based FAN events. |
| ONS Wallet File | Location of ONS Wallet File (including the file name) | The location of the Oracle wallet file in which the SSL certificates are stored. Only required when the ONS client is configured to communicate with ONS daemons using SSL. |
| ONS Wallet Password & Confirm ONS Wallet Password | The wallet password | The wallet password attribute that is included as part of the ONS client configuration string. This attribute is only required when ONS is configured to use the SSL protocol. |
Step 9: Click on Test All ONS Nodes to see if the connection is successful. Once the connection test succeeds, click the Next button.
Step 10: Select the Target(s) in the next page and click the Finish button.
Make sure to specify the managed server as target for the GridLink Data Source and change the connection pool settings by executing the following steps:
-
Select the newly created GridLink Data Source
-
Click on the tab Connection Pool
-
Expand the Advanced node at the bottom of the page to display all properties and set the following:
| Property | Value |
|---|---|
| Initial Capacity | 0 |
| Test Connections On Reserve | Checked |
| Test Frequency | 300 |
| Connection Creation Retry Frequency | 30 |
| Seconds to Trust an Idle Pool Connection | 10 |
Set the following driver property:
| Prperty | Value |
|---|---|
| oracle.net.CONNECT_TIMEOUT | 10000 |
3.2.4 Installing the UI Customization Library through WLS Admin Server Console
To enable the creation of site-level UI Customizations, without having to change the OHI Application itself, an initially empty library called custom.oracle.healthinsurance needs to be installed before the OHI application can be installed.
Step 1: Login to the Admin Server console (for example: http://machine.domain:port/console).
Step 2: Click the "Deployment" link and then click on the "Install" button. If the Install button is disabled, click the Lock & Edit button first (in the upper left section of the page).
Step 3: Select the path where the library custom.oracle.healthinsurance.war file is located (<OHI_ROOT>\lib) and click the "Next" button.
Step 4: Select the option "Install this deployment as a library" and click on "Next" button.
Step 5: Ensure that the General - Name is set to custom.oracle.healthinsurance. This is the name the OHI Application refers to when loading the library, so this is the name under which it must have been installed. The OHI Application will automatically load the highest version of all installed libraries with this deployment name. Then click on the "Next" button.
Step 6: Click on "Finish" button. You should see a success message. The library is now installed. Note: if you had to click Lock & Edit in step 1, you now have to click Activate Changes
Installing the Jersey Library through WLS Admin Server Console
Please follow the above steps to install the jersey libararies through weblogic console. The libraries to be installed are packaged along with weblogic and can be found at location: <WLHOME>/Middleware/wlserver_10.3/common/deployable-libraries.
The name of the libraries are following:
-
jersey-bundle-1.1.5.1.war
-
jsr311-api-1.1.1.war
3.2.5 Installing The OHI Product Definition Application Through WLS Admin Server Console
The OHI applications are delivered in a so called Java Enterprise Archive (EAR) which will be installed through the WLS Admin Server Console. In order to do that, perform the following steps.
Step 1: Login to the Admin Server console (for example: http://machine.domain:port/console).
Step 2: Click the "Deployment" link and then click on the "Install" button.
Step 3: Select the path where the EAR file is located and click the "Next" button.
Step 4: Select the option "Install this deployment as an application" and click on "Next".
Step 5: Click on "Finish" button. The OHI Application is now installed.
Step 6: If you are deploying the application to cluster, in "Select deployment targets" page, select the Clusters target.
3.2.6 Changing the Context-Root for UI or Web Services
To change the default context-root of OHI Product Definition web application (which is "/proddef") or web services deploy the application with a customized deployment plan.
Perform the following steps for a new deployment of the application:
Step 1: Edit the value of the variable UI_CONTEXT_ROOT in <OHI_ROOT>/application/plan/Plan.xml to suit your requirements.
Step 2: The following example shows how the context-root for a web service can be changed using the deployment plan (the example does so for the context-root of the File Import web service):
...<variable> <name>FILEIMPORT_CONTEXT_ROOT</name> <!-- Here claims is the new context root which will overwrite the default context root --> <value>new-ohi-common-ws-fileimport</value></variable>...<module-override> <!-- Copy the name of the EAR (including .ear file extension) from <OHI_ROOT>/application/app/ dir --> <module-name>NAME_OF_THE_EAR</module-name> <module-type>ear</module-type> <module-descriptor external="false"> <root-element>application</root-element> <uri>META-INF/application.xml</uri> <variable-assignment> <name>FILEIMPORT_CONTEXT_ROOT</name> <!-- Here ohi-common-ws-fileimport refers to the default context root. See the appendix of the Installation Guide for the default context roots of web services --> <xpath>/application/module/web/[context-root="ohi-common-ws-fileimport"]/context-root</xpath> <operation>replace</operation> </variable-assignment> </module-descriptor></module-override>--
The module names for the web services are listed in an appendix.
Step 3: The EAR and Plan.xml (deployment plan) are packaged under a directory named "application" in the release bundle (See the directory structure below). It is recommended to copy the "application" directory to a location (this directory will be referred as <INSTALL-ROOT> hereafter) and optionally rename the directory (for example, rename to OHIProdDef).
Step 4: To install the application using Administration Console, select the directory <INSTALL-ROOT> instead of selecting the EAR file. By default, the Administration Console will use a deployment plan named Plan.xml, if one is available in the \plan subdirectory.
3.2.6.1 Changing OHI Product Definition Session Timeout
OHI Product Definition application does not ship with default session timeout. Instead, it leverages WebLogic Server's default session timeout - which is 3600 seconds (1 Hour). It is possible to change this default session timeout value through WebLogic Server's Admin Console. Follow the steps below to change the default session timeout.
Follow the section Changing the Context-Root for UI or Web Services to deploy OHI Product Definition application in order to change the session timeout through WebLogic Server Admin Console.
Step 1: Login to WebLogic Server Admin Console
Step 2: Click on Deployments link and expand OHI Product Definition application tree
Step 3: Click on the name of the UI application (by default it is proddef unless the context-root is changed as mentioned in the section "Changing the Context-Root for UI or Web Services" in Modules section.
Step 4: Make sure that the name of the module is ohi-proddef-ui.war
Step 5: Click on Configuration tab and change the default Session Timeout (in seconds) from 3600 seconds (1 Hour) to suit your needs and click on Save button.
You may get into trouble if the load balancer session timeout is shorter than WebLogic session timeout. So, it is important to set load balancer session timeout in align with WebLogic session timeout
Step 6: Click on Deployments link and select OHI Product Definition application. Click on Update button
Step 7: Select the first option in Update Application Assistant and click on Finish button.
Step 8: After activating changes, restart WebLogic Server.
3.3 Validate Installation
Validate the installation by performing the following steps:
Note: if users have not been provisioned yet, the application cannot be accessed.
-
Point a web browser to the home page of the application and verify that a login screen is displayed. The URL for the home page is http://machine.domain:port/proddef.
-
Using a web browser, verify that the Web Service WSDL's are available. The URL's for the accessing the Web Service WSDL's are listed elsewhere in this guide.
3.4 Configuring OHI Product Definition properties file
A changed version of the ohi-proddef.properties file may be delivered in a new OHI Product Definition release.
The following tables describe the properties that are maintained in this file.
| Category | Parameter | Value | Explanation |
|---|---|---|---|
| File Import | ohi.ws.fileimport.filesrootdirectory | . | Directory paths used for File Import will be prepended with the given root directory. This is for security reasons, it ensures that files are stored in a specific area only |
| Dynamic Logic | ohi.dynamiclogic.classes.directory | . | Path to directory in which the system generates Dynamic Logic classes |
OHI Product Definition User Interface related properties
The following table lists other user interface related properties:
| Category | Parameter | Value | Explanation |
|---|---|---|---|
| User Interface | ohi.environment.identifier | Samples: "User Acceptance Test", "Development". | Text string that is displayed on the home page of the system that helps the user to identify the environment |
| User Interface | ohi.ui.maxrowstoretrieve | Suggested default is 200. | Maximum number of rows retrieved to show in a UI table. Note that memory usage and page load times are impacted by this value. |
The following table lists Product Definition processing related properties:
| Category | Parameter | Value | Explanation |
|---|---|---|---|
| Product Definition Processing | ohi.processing.fillthreshhold | OPTIONAL
Positive integer value. Default 10 |
Suggested value is a multiple of the number of CPU cores available to the managed server. Determines the number of tasks that will be submitted for processing at any given time. |
| Product Definition Processing | ohi.processing.filldepth | OPTIONAL
Positive integer value. Default 30 |
Suggested value is 1 less than number of CPU cores available to the managed server. Determines when the system will look for more tasks to be submitted for processing. |
| Product Definition Processing | ohi.processing.maxIncompleteAttempts | OPTIONAL
Positive integer value. default is 100000 |
Number of times a task can resolve as "incomplete" before it's marked as in error. |
| Product Definition Processing | ohi.processing.maxErrorAttempts | OPTIONAL
Positive integer value. Default is 3 |
Number of times a task can resolve as "errored" before it stops a task flow. |
| Product Definition Processing | ohi.processing.attemptLogLevel | OPTIONAL
Integer Value >= 0. Default is 0 |
A value of greater than 0 means data for failed task processing attempts will be retained. |
| Product Definition Processing | ohi.processing.retryimmediate | OPTIONAL
Boolean [true,false]. Default is false |
Determines if a failed task is retried immediately, or re-queued for another attempt after a delay. |
| Product Definition Processing | ohi.processing.defaultdelay | OPTIONAL
Positive Integer. Default is 3 |
Default delay in seconds used when a failed task is re-queued for another attempt. Is overridden if a delay is set on the task type. |