Installation | ||
---|---|---|
Previous | Next | |
System Requirements | Deploying Deliverables |
In the following section:
semarchy-di-designer.zip
file refers to the
Semarchy Convergence for DI- Full Setup file that you can download to install Semarchy Convergence for Data Integration. The name of this file varies as it includes the platform information, product version and build number.
<semarchy_di>
refers to the installation folder of Semarchy Convergence for DI.
To install the Designer:
semarchy-di-designer.zip
) corresponding to your platform.
semarchy-di-designer.zip
file in your machine. This will create a
semarchy_di
sub-folder. This sub-folder will be referred to as
<semarchy_di>
(the Semarchy Convergence for DI installation directory).
<semarchy_di>
folder.
semarchy.exe
. The DI Designer starts.
<semarchy_di>
folder.
./semarchy
. The DI Designer starts.
<semarchy_di>/runtime
folder and run
chmod 755 *.sh
to make the runtime scripts executable.
workspace
folder in its installation directory. To install it in a different location:
The
<semarchy_di>
directory contains the following sub-folders:
/samples
contains the files for running this getting started tutorial and other samples.
/workspace
contains the workspace that you have created. Note that you can have several workspaces for a single installation. You can locate these workspaces anywhere in your file system.
/templates
contains the templates provided out of the box with Semarchy Convergence for DI.
/runtime
contains the Semarchy Convergence for DI runtime engine binary and startup scripts.
/plugins
and
configuration
contain the binaries and configuration files for the DI Designer.
Important: The Runtime Engine is not shipped as a standalone installer or package. It is deployed the first time you start a Designer in the
/runtime
sub-folder. You must first install and start a designer in order to deploy runtime engines on your servers.
Before you begin the installation:
STAMBIA_JAVA_HOME
environment variable to the folder located above the
bin
folder of your JDK
To install the runtime engine:
runtime
directory from a Semarchy Convergence for DI Designer installation to the target folder.
runtime
folder.
temp
,
build
and
sessions
sub-directories.
STAMBIA_HOME
environment variable pointing to the
runtime
folder.
./startengine.sh
command from the
runtime
folder.
To install the runtime engine on Windows:
runtime
directory from a Semarchy Convergence for DI Designer installation to the target folder.
startengine.bat
command from the
runtime
folder.
To configure the runtime engine as a windows service, use the following scripts available in the
runtime
directory:
installEngineAsService.bat –i
installs the runtime as a service.
installEngineAsService.bat –r
removes the service
Semarchy support services may request that you modify the service configuration using the
external\stambiaService\conf\stambiaEngine.conf
file. You do not need to edit this file for a standard configuration.
Warning: Any parameter change in the
properties
sub-folder requires that you remove and reinstall the Windows service to take these changes into account.
Tip: The user used to start the Runtime Engine as a Windows service should be changed to a user with network abilities, usually a domain user.
To connect or use database technologies with their own drivers, you must add these drivers to your Architecture and Setup Guide installation for each machine running a Runtime Engine or Designer.
To install and configure an additional driver:
runtime/lib/jdbc/
folder.
runtime/lib/jdbc/
sub-folder of your Architecture and Setup Guide installation.
Two environment variables are used by the runtime engine and may have to be set specifically for your configuration:
STAMBIA_JAVA_HOME
: Path to the JVM used by the runtime.
STAMBIA_PROPERTIES_LOCATION
: Path to the
properties
folder.
Note: In order to facilitate future upgrades of the runtime engine, it is recommended to copy the
properties
sub-directory to another location and to set theSTAMBIA_PROPERTIES_LOCATION
environment variable to points to this new location. With such a configuration, an entire replacement of theruntime
folder for an upgrade will not erase the configuration.
If you want to store logs in a specific database schema, you must configure a connection to this database.
To configure this connection, add in the
properties/logs
sub-folder a file configuring the connection the database, and name it
log[name].xml
where
[name]
describes the database to connect.
Tip: Sample connection files are available from the
properties/logs/samples
sub-folder.
The example below is a connection to an Oracle database.
<?xml version="1.0" encoding="UTF-8"?>
<repository>
<logs>
<log userLogName="oraclePROD" autoUpdate="true" userLogClass="com.indy.engine.userLog.RdbmsUserLog" enable="false">
<parameter name="userLogRdbmsDriver" value="oracle.jdbc.driver.OracleDriver"/>
<parameter name="userLogRdbmsUrl" value="jdbc:oracle:thin:@[host]:[port]:[sid]"/>
<parameter name="userLogRdbmsUser" value="user"/>
<parameter name="userLogRdbmsPassword" value="password"/>
<!-- parameter name="userLogRdbmsEncryptedPassword" value="password"/ -->
<parameter name="userLogRdbmsVarcharType" value="varchar2"/>
<parameter name="userLogRdbmsVarcharMaxSize" value="4000"/>
<parameter name="userLogRdbmsClobType" value="clob"/>
<parameter name="userLogRdbmsBlobType" value="blob"/>
<parameter name="userLogRdbmsNumericType" value="number"/>
<parameter name="userLogRdbmsDeleteSyntaxe" value="Delete from"/>
<parameter name="userLogRdbmsdeliverableFormat" value="text"/>
<parameter name="userLogRdbmsPropertyMaxVarcharSize" value="1000"/>
<parameter name="userLogRdbmsPropertyMaxClobSize" value="10000"/>
<parameter name="userLogRdbmsPropertyBinaryFormat" value="compressed"/>
</log>
</logs>
</repository>
In the example, you can modify the following parameters to connect to your own Oracle database and schema:
After creating the connection file, reference it from the
runtime/properties/engines/commonParameters.xml
by adding the following line:
<include file="../logs/log[name].xml"/>
Finally, in the
commonParameters.xml
file, specify the default logging storage. Note that the value specified must match the userLogName value from the connection configuration file.
<engineParameters>
<parameter name="userLogDefaultName" value="OraclePROD"/>
<!-- The value specified must match the userLogName value from the connection configuration file-->
…
</engineParameters>
In the
engineParameters4200.xml
file, or in a copy of this file, change as needed the RMI, SOAP, etc. listening ports.
<engineParameters>
…
<parameter name="rmiPort" value="42000"/>
<!--<parameter name="rmiCallbackPort" value="42000"/>-->
<parameter name="internalDbTcpPort" value="42100"/>
<parameter name="internalDbWebPort" value="42101"/>
<parameter name="soapServerPort" value="42200"/>…
</engineParameters>
Note: It is recommended when changing the ports to copy the file and name the copy with the number of the RMI port. For example:
engineParameters5500.xml
By default, the scheduler stores the schedules in an embedded database. It is possible to change this storage to another location.
When the
org.quartz.jobStore.dataSource
property is set to
internal
(which is the default value), the scheduler stores its schedules in the runtime embedded database.
To store schedules in a different database, you must first create a database schema, and run in this schema the script to seed the storage structure. Scripts for the supported database technologies are available from the
/scripts/scheduler/
sub-folder.
Then you must configure the
/properties/engineScheduler.properties
file to connect to this new storage, as shown in the example below for an Oracle Server.
org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.useProperties=false
# org.quartz.jobStore.dataSource=internal
org.quartz.jobStore.dataSource=database01
org.quartz.jobStore.tablePrefix=QRTZ_
org.quartz.jobStore.isClustered=false
#============================================================================
# Configure Datasources
#============================================================================
org.quartz.dataSource.database01.driver = oracle.jdbc.driver.OracleDriver
org.quartz.dataSource. database01.URL = jdbc:oracle:thin:@[host]:[port]:[sid]
org.quartz.dataSource.database01.user = oracle_user
org.quartz.dataSource.database01.password = oracle_password
org.quartz.dataSource.database01.maxConnections = 5
org.quartz.dataSource.database01.validationQuery=
It is possible to select those of the services (Scheduler, SOAP, Embedded H2 Database) should be started with the runtime engine.
The parameters for the services are located in the
engineParameters42000.xml
and
commonParameters.xml
files
<parameter name="startInternalDb" value="true"/>
|
Start embedded H2 database | |
<parameter name="startSoapServer" value="true"/>
|
Start SOAP service | |
<parameter name="launchSchedulerEngine" value="true"/>
|
Start scheduler | |
<parameter name="launchExecutionEngine" value="true"/>
|
Start execution engine | |
<parametername="launchReportEngine" value="true"/>
|
Start reporting |
Note: A standard runtime engine should at least start the Execution Engine and Reporting.
In the
commonParameters.xml
file, two folder parameters should be reviewed and modified as needed.
<parameter name="deliverableFolder" value="build/deliveries"/>
|
Location of the deliveries | |
<parameter name="temporaryFolder" value="temp"/>
|
Runtime temporary folder |
A runtime can start with a specific configuration file.
To specify this file, use the
STAMBIA_CONF_FILE_LOCATION
environment variable.
By default, the value configured in the file
initvariable.sh|bat
in the following line:
STAMBIA_CONF_FILE_LOCATION=$STAMBIA_PROPERTIES_LOCATION/engineParameters.xml
You can configure an automatic purge of the runtime session logs.
To automate the log purge:
startcommand.sh
(Linux/UNIX) or
startcommand.bat
(Windows) script.
schedule purge keep <number> <minute|hour|day|session>
cron <cronExpression>
[sessionname <name,name2,...>]
[status <done,error,killed>]
[on host <hostname>]
[port <hostport>]
The command defines:
For example, to keep 90 days of log history for all jobs and schedules and purge every evening at 23:00:
schedule purge keep 90 day cron "0 0 23 * * ?"
Previous | Top | Next |
System Requirements | Deploying Deliverables |