When packaging a project on Corticon Studio for deployment as a Decision Service on a Corticon Server, a Datasource Configuration file provides the database configurations and credentials that were used in the project.
Note: When you are running and testing in Corticon Studio, the Datasource configuration and mapping information is saved in the project's Vocabulary file. It does not need a Datasource Configuration file.

To generate a Datasource Configuration file:

  1. With the project's Vocabulary open in its editor, select Vocabulary > Datasource Configuration File > Export, as shown:


  2. All the defined connections to external data sources are packaged into a single file XML, typically named, datasources.xml. The file content might look like this: 
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<decisionService>
    <datasources>
        <database name="Treatment Data">
            <authentication-type>Basic</authentication-type>
            <connection-url>jdbc:progress:sqlserver://localhost:1433;databaseName=CMSDetail</connection-url>
            <database-driver>com.corticon.database.id.MsSql2014</database-driver>
            <password>045032017061061017032045</password>
            <username>061046</username>
        </database>
        <database name="Patient Data">
            <authentication-type>Kerberos</authentication-type>
            <connection-url>jdbc:progress:sqlserver://localhost:1433;databaseName=PatientRecords</connection-url>
            <database-driver>com.corticon.database.id.MsSql2014</database-driver>
        </database>
    </datasources>
</decisionService>

When authentication-type="Kerberos", the username andpassword parameters are not included.

You can specify a preferred name and location for the file, although colocating it with its Decision Service file, or within its related project folder is a good idea.

Note: Because data integration carries the potential for data loss or corruption due to unintended updates, it is a good idea to use a test instance of a database whenever testing database-enabled Rulesheets and Ruleflows from Studio. Then, if unintended changes or deletions are made during rule execution, only test database instances have been changed, not production databases. Even when using test instances, you may want to restrict the ability to read and update connected databases to those users who understand the possible impact. For other rule modelers without a solid understanding of databases, you may want to provide them with read-only access.

There are several techniques for deployment, as described in the section How to package and deploy Decision Services . This section will focus on one, Use Studio to compile and deploy Decision Services .

Managing user access on Corticon Server

Typically, enterprises constrain developers to appropriate database products. As data integration carries the potential for data loss or corruption due to unintended updates, developers are typically limited a test instance of a database when testing from Studio. If unintended changes or deletions are made during rule execution, then only test database instances have been changed. When deploying to Corticon Server, it is a good practice to have servers reserved for developer integration testing to the test databases through the user-acceptance test phase.

Managing database connections on Corticon Server

The handoff to production administrators will typically recast the Datasource configurations to the pre-production server locations and credentials followed by validation tests. Production might require another adjustment of the database configuration.

However, notice that the username and password values are very different from the credentials that were entered. These values were encrypted when the database access file was created and will be decrypted when they are implemented in a decision service. You can use the following utility to encrypt the required credentials.

Encrypting database credentials defined in the Datasource Configuration File

To use Corticon's proprietary encryption algorithm to encrypt credentials:

  1. Obtain the credentials you want for each of the Datasources. Use those values to replace myServerUser and myServerUserPassword in the following procedure.
  2. In a Corticon Server installation, open a Command Window at [CORTICON_HOME]\Server\bin\.
  3. Type corticonManagement -en -i myServerUser. An encrypted String for the username is output. Then type corticonManagement -en -i myServerUserPassword. An encrypted String is output. The procedure looks like this:


  4. Copy the encrypted String to the appropriate Datasource in the Datasource configuration file and enter it as the value for the username. Then similarly copy the encrypted password String as the value for the user's password.
  5. Colocate the revised Datasource configuration file with the appropriate instance of the Decision Service on the Corticon Server.
Note: When using CDD deployment, the database access properties file is identified within the CDD file. When using the Web Console or APIs for deployment you specify the file at the time of deployment.

Using the Datasource XSD file

Every Corticon Studio and Corticon Server installs an XSD file that specifies how to formally describe the elements in Datasource configuration XML files. You can use this file to verify the content in your documents. The file datasourceConfig.xsd is located at [CORTICON_HOME]/Studio/lib.