Managing the Platform |
Previous
|
|
Next
|
Managing Model and Data Editions |
|
Managing Execution |
The platform consists of several components that can be managed from the
Administration Console perspective.
These components include the Engine, the Integration Batch Poller, the Notification Servers and Notification Policies, the Plug-ins and the Web Services.
Managing the Execution Engine
Accessing the Execution Engine
To access the execution engine:
- In the
Administration view, double-click the
Execution Engine node.
The
Execution Engine editor opens.
The Execution Engine Editor
This editor displays the list of queues grouped by clusters. Queue currently pending on suspended jobs appear in red.
The list of queues and clusters displays the following information:
-
Cluster/Queue Name: the name of the cluster or queue.
-
Status: Status of the queue or cluster. A queue can be either
READY,
SUSPENDED or
BLOCKED. A cluster may be in a
BLOCKED or
READY status.
-
Queued Jobs: For a queue, the number of jobs queued in this queue. For a cluster number of jobs queued in all the queues of this cluster.
-
Running Jobs: For a queue, the number of jobs running in this queue (1 or 0). For a cluster, the number of jobs running in all the queues of this cluster.
-
Suspend on Error: Defines the behavior of the queue on job error. See the
Troubleshooting Errors section for more information.
From the
Execution Engine editor, you can perform the following operations:
Stopping and Starting the Execution Engine
To stop and start the execution engine:
- In the
Administration view, double-click the
Execution Engine node. The
Execution Engine editor opens.
- Use the
Stop this component and
Start this component buttons in the editor’s toolbar to stop and start the execution engine.
Note: Stopping the execution engine does not kill running jobs. The engine stops after all running jobs are completed. Beside, the content of the queues is persisted. When the execution engine is restarted, the execution of queued jobs proceeds normally.
Managing the Integration Batch Poller
The
Integration Batch Poller polls the integration batches submitted to the platform, and starts the integration jobs on the execution engine. The polling action is performed on a schedule configured in the batch poller.
Stopping and Starting the Integration Batch Poller
To stop and start the integration batch poller:
- In the
Administration view, double-click the
Integration Batch Poller node. The
Integration Batch Poller editor opens.
- Use the
Stop this component and
Start this component buttons in the editor’s toolbar to stop and start the integration batch poller.
Note: Stopping the batch poller does not kill running jobs, and does not prevent new batches to be submitted. When this component is stopped, the submitted batches are simply not taken into account and no jobs is queued on the execution engine until the batch poller is restarted.
Configuring the Integration Batch Poller
The integration batch poller configuration determines the frequency at which submitted batches are picked up for processing.
To configure the integration batch poller:
- In the
Administration view, double-click the
Integration Batch Poller node.
- In the
Integration Batch Poller editor, choose in the
Configuration section the polling frequency:
- Weekly at a given day and time.
- Daily at a given time.
- Hourly at a given time.
- Every n second.
- With a UNIX Cron syntax. See Cron for the details of this syntax.
- Press
CTRL+S to save the configuration.
Note: It is not necessary to restart the integration batch poller to take into account the configuration changes.
In the
Advanced section, set optionally the following logging parameters:
-
Job Log Level: Select
Exclude Skipped Tasks to exclude from the job log the tasks that are skipped. Select
Include All Tasks to log all tasks..
-
Execution Monitor Log Level:: Logging level [1...3] for the execution console for all the queues.
-
Enable Conditional Execution: A task may be executed or skipped depending on a condition set on the task. For example, a task may be skipped depending on parameters passed to the job. Disabling this option prevents conditional executions and forces the engine to process all the tasks.
Configuring Notifications
Notifications are emails sent to users via
Notification Servers. These notifications are sent under certain conditions when a job finishes.
Configuring Notification Servers
A
Notification Server is an SMTP server used for sending notification emails. This server is either:
- Managed by the application server hosting the Semarchy Convergence for MDM application. Such server is accessed using a Java Mail Session JNDI URL. For more information about configuring Mail Session, see the
"Semarchy Convergence for MDM Installation Guide".
- A remote SMTP server. Semarchy Convergence for MDM connects to this server as an SMTP client, using the host, port and authentication information.
Note: Notifications servers are also used by Human Workflows to send notifications to roles when a task is assigned. Make sure to configure a default working notification server if you want to enable notifications in human workflows.
Creating a Notification Server
To create a notification server:
- In the
Administration view, double-click the
Notification Servers node. The
Notification Servers editor opens.
- Select the
Notification Servers list, right click and select
New Notification Server. The
Create New Notification Server wizard opens.
- To configure a server managed in the application server:
- Select
Provided by the JEE Application Server and then click
Next.
- In the second wizard page, enter the following information:
-
Name: Internal name of the notification server.
-
Label: User-friendly label for the server. Note that as the
Auto Fill box is checked, the
Label is automatically filled in. Modifying this label is optional.
-
From User: Email address of the sender of the notifications from this server. This address is also used in the reply-to address for notification emails.
- Click
Next.
- In the
JNDI URL field, enter the JNDI URL of the Java Mail Session service available in the application server.
- Click
Next.
- Click
Finish.
- To configure a remote SMTP server:
- Select
Manually Configured SMTP Server and then click
Next.
- In the second wizard page, enter the following information:
-
Name: Internal name of the notification server.
-
Label: User-friendly label for the server. Note that as the
Auto Fill box is checked, the
Label is automatically filled in. Modifying this label is optional.
-
From User: Email address of the sender of the notifications from this server. This address is also used in the reply-to address for notification emails.
- Click
Next.
- In the
SMTP Notification Server page, enter the
SMTP Host Name and
SMTP Port.
- Click
Finish.
Configuring Notification Server Properties
SMTP servers may require advanced parameters to handle authentication and security. These parameters must be provided as properties of the notification server.
To configure the notification server properties:
- In the
Notification Servers editor, double-click the notification server that you want to edit. The
Notification Server editor opens.
- Expand the
Notification Server Properties option group, and use this table to add new properties as value pairs.
- Press
CTRL-S to save the configuration.
Commonly used properties include:
-
mail.smtp.auth
: Set to
true
if the SMTP server requires authentication.
-
mail.smtp.user
: The user name to authenticate to the SMTP server
-
password
: This user’s password.
-
mail.smtp.starttls.enable
: enable the use of a TLS-protected connection before the login command.
Refer to the JavaMail API documentation for a list of supported properties.
Testing a Notification Server
After configuring the notification server, it is recommended to run a test email on this server.
To test a notification server:
- In the
Notification Servers editor, select the notification server that you want to test, right-click and select
Test Configuration.
- Enter a comma-separated list of email address recipients for this test and then press
OK.
- If the test is successful, a test email is sent from the platform to the recipients. If not, an error window appears.
Configuring a Job Notification Policy
With a notification server configured, it is possible to create notification policies.
To create a notification policy:
- Open the
Data Locations perspective.
- In the
Data Editions view, right-click the
Job Notification Policies node and select
New Job Notification Policy. The
Create New Job Notification Policy wizard opens.
- In the first wizard page, enter the following information:
-
Name: Internal name of the notification policy.
-
Label: User-friendly label for the notification policy. Note that as the
Auto Fill box is checked, the
Label is automatically filled in. Modifying this label is optional.
-
Description: Detailed description of the policy.
-
Notification Server: Select the notification server that will be used to send these email notifications.
-
Subject: Subject of the notification email.
-
Body: Body of the notification email.
- Click
Next.
- Click the
Add Recipient button.
- In the
Define Job Notification Recipients dialog, select the recipients (roles) of the notification email, click the
Add >> button and then click
Finish.
- Click
Next.
- Enter the conditions for sending a notification. These conditions apply to a completing job and include:
-
Job Name Pattern: Name of the job. Use the
_
and
%
wildcards to represent one or any number of characters.
-
Notify on Failure: Select this option to send notification when a job fails or is suspended.
-
Notify on Success: Select this option to send notification when a job completes successfully.
-
... Count Threshold: Select the maximum number of errors, inserts, etc allowed before a notification is sent.
- Click
Finish.
Note: If you define a
Job Name Pattern,
Notify on Failure and a
Threshold, a notification is sent if a job matching the pattern fails
or to reaches the threshold.
Configuring Variable Value Providers
Semarchy Convergence for MDM uses variables defined in models to enforce certain data governance policies for a user’s session.
For more information about model variables, see the
"Semarchy Convergence for MDM Developer’s Guide".
A Variable Value Provider is a system that can be queried by Semarchy to retrieve the values for these variables. Typically, this system is a server containing information about the user connected to Semarchy Convergence for MDM.
Two type of variable value providers are supported out-of-the-box:
-
JDBC Variable Provider: This variable value provider is a relational database that is accessed through a JDBC connection. Convergence for MDM can issue SQL statements against this database to retrieve variable values. For example, an employee database that can be queried to retrieve the
country of the connected user.
-
LDAP Variable Provider: This variable value provider is a directory server that is accessed using the LDAP protocol. Convergence for MDM can issue queries against this directory server to retrieve variable values. For example, an LDAP directory that can be used to retrieve the
organizational unit of the connected user.
Variable value providers are configured in the repository, and can be used by any model in this repository.
Warning: When working with a deployment repository, make sure to configure the variable value providers used in the models before importing or deploying them in this repository.
Creating a Variable Value Provider
To create a variable value provider:
- In the
Administration view, double-click the
Variable Value Providers node. The
Variable Value Providers editor opens.
- Select the
Variable Value Providers list, right-click and then select
New Variable Value Provider. The
Install Variable Value Provider wizard opens.
- Enter the following information:
-
Name: Internal name of the variable value provider.
-
Label: User-friendly label for the variable value provider. Note that as the
Auto Fill box is checked, the
Label is automatically filled in. Modifying this label is optional.
- Select the
Plug-in ID corresponding to the variable value provider type:
LDAP Variable Provider or
JDBC Variable Provider.
- Click
Next.
- Click the
Edit Expression button.
- In the the
Variable Value Configuration dialog, enter the configuration information. This information differs depending on the selected Plug-In.
- For a JDBC Variable Value Provider, enter the following information:
-
JNDI Data Source Name: Name of the JDBC datasource defined in the application server used to connect the database acting as the variable value provider. For example
java:comp/env/jdbc/MY_DATA_SOURCE
.
- For an LDAP Variable Value Provider, enter the following information:
-
LDAP Host: Name or IP address of the LDAP server.
-
LDAP Port: Listening port of the LDAP server. The port is typically 389 for non-SSL connections, and 636 for SSL connections.
-
Use SSL: Check this options to use SSL to connect to the LDAP server.
-
User: Name of the user used to retrieve data from the LDAP Server. Note that this user should have read privileges to the LDAP structure.
-
Password: This user’s password.
- Click
OK to close the
Variable Value Configuration dialog.
- Click
Finish.
The variable value provider is added to the list.
Testing the Variable Value Provider Configuration
After configuring a new variable value provider, it is recommended to test its configuration.
to test a variable value provider configuration:
- In the
Variable Value Providers editor, select of the variable value provider in the list.
- Right-click and select
Test Configuration.
A message indicates whether the connection test was successful or not.
Warning: The configuration test only tests the connection information, but does not check the privileges granted to the user to retrieve the values from the provider.
Managing Plug-ins
Semarchy Convergence for MDM allows extending its capabilities using Java code and external APIs. Using the Open Plug-in Architecture, existing services or information systems can contribute to the master data processing and enrichment. You can extend the
Enrichment and
Validation capabilities in Semarchy Convergence for MDM through user-defined plug-ins.
For detailed information about plug-in development and packaging, see the
"Semarchy Convergence for MDM Plug-in Development Guide".
A Plug-in is delivered as a jar file bundle that must be deployed in each Semarchy Convergence for MDM application instance running integration jobs that use the plug-in. You do not need to restart the server to take new or updated bundles into account.
These bundles are tagged with a version number. As a consequence, updating an existing plug-in with a newer version of this plug-in will automatically make the platform work with the newer plug-in version. The deployment process installs a new plug-in or replaces an existing plug-in version with a new one.
To deploy a plug-in:
- Open the
Administration Console perspective.
- Double-click the
Plug-ins node in the
Administration view.
- Click the
Install or Update Plug-in button in the upper right corner of the
Plug-ins editor. The
Install/Update Plug-ins dialog opens.
- Click the
Browse button and select the plug-in binary file. For example:
com.acme.phoneStandardizer_1.0.0.jar
.
- Click
OK. A
Status window shows the number of plug-ins installed or updated.
- Your session is closed to take this new plug-in into account. Click the link to restart the session on the
Overview perspective.
- Open the
Administration Console perspective.
- Double-click the
Plug-ins node from the
Administration view.
The plug-in now appears in the list, and can be used in the models and the integration jobs.
Warning: Make sure to install the plug-ins required by the jobs of a model before creating a data edition using this model. If a job requires a plug-in that is not installed, then the job fails. The plug-in can be installed and the job resumed after the installation.
To uninstall a plug-in:
Open the
Administration Console perspective.
- Double-click the
Plug-ins node in the
Administration view.
- Select the plug-in in the list.
- Click the
Uninstall Selected Plug-ins button in the editor’s toolbar.
Managing Web Services
The
Web Services are not configured to start by default. It is possible to start them manually or configure them to start with the platform.
To access the Web Service Manager:
- Open the
Administration Console perspective.
- Double-click the
Web Services Manager node in the
Administration view. the
Web Services Manager Configuration editor opens.
This editor displays the various web services with their status, and allows managing web service startup:
- Select the
Auto-Start option to have a web service start automatically when the application starts. Press
CRTL+S to save this configuration change.
- Use the
Start,
Stop and
Restart buttons in the editor’s toolbar to start, stop or restart the selected web service.
- Use the
Restart all Web Services in the editor’s toolbar to stop all web services and restart those configured to auto-start.
- When a web service is started, you can access its WSDL by double-clicking its
WSDL URL in the services list. In the
Web Service Details dialog that opens, click the WSDL URL link to view the WSDL content.