Skip to content

Manage Servers

In order to harvest metadata (model import) from a tool (e.g. database, DI/ETL, BI tool, etc.), the local MetaKarta (Default) Server may not be able to support that tool and therefore require a remote harvesting server (agent) in the following cases:

  • a bridge running on Microsoft Windows only (such as COM based tools like SAP BusinessObjects, MicroStrategy), while the MetaKarta Server is running on Linux (on Prem or on Cloud)

  • a bridge requiring the tool (often the client) to be installed in order to access its SDK. (such as Oracle DI or Talend DI), while the MetaKarta server is running on the cloud (with no local file system access)

  • a bridge requiring access to local files / drivers (such as Database JDBC bridges), while the MetaKarta server is running on the cloud (with no local file system access)

  • a bridge connected to a tool running on a different network (such as a MetaKarta server on cloud harvesting from sources on prem).

Go to supported tools for more details on the above requirements:

Installing a remote bridge server is equivalent to installing MetaKarta on an application server, except that one specifies Metadata Harvesting Server Only in the Application Server tab in the setup.bat utility and no license is required and thus it will not have an available web based UI. Please refer to the installation instructions for more details and special instructions for MetaKarta installations in the cloud.

Once such a remote harvesting server is installed and working, one must add it to the list of servers in MetaKarta.

To add a remote harvesting server to MetaKarta.

Steps

  1. Sign in as a user with at least the Application Administrator capability global role assignment.

  2. Go to MANAGE > Servers in the banner.

  3. Specify the HEARTBEAT FREQUENCY.

In order to send out notification when a harvesting server goes down, you must specify a HEARTBEAT FREQUENCY for the application server to check the status of the harvesting servers. By default, this is disabled and no notifications will be sent.

  1. Click +Add to add a server or click on the line in the list for an existing server.

  2. Specify

  3. The Name to refer to this remote server by

  4. The Type of remote harvesting server to create

  5. Local Network -- Remote harvesting server that is within the same domain as the MetaKarta server. In such case, the MetaKarta Server is requesting operations to be performed (in real time when needed) to its registered MIMB Agent. E.g., where the MetaKarta Server is on Linux and needs to import metadata from a MIMB Agent on Windows (for Windows only bridges like Erwin DM, or SAP BusinessObjects).

The default installation of a remote harvesting server does not allow for a Local Network connection for security reasons. You must first use setup.sh -wa MIMBWebServices on that remote harvesting server to be reachable by the main MetaKarta server. For these reasons, it is better to always use Over the Web (Cloud) even if both servers are on the same local network.

  1. Over the Web (Cloud) -- Remote harvesting server that is local to the organization but the MetaKarta server is Cloud-based. In such case, the MIMB Agent is requesting operation to do on regular basis (every 40s) from its registered MetaKarta Server. E.g., where the MetaKarta Server is on the cloud and needs to import metadata from another Server on prem.

Most operations requested by the MetaKarta server to the MIMB agents are model imports (i.e. metadata harvesting), however a particular operation is to patch the MIMB agent with a MIMB OEM cumulative patch.

  1. The URL for this remote server (generally one only need update the machine name inside the URL signature suggested) applies only for Local Network remote harvesting servers. It is of the form

    http://:/MIMBWebServices

    where <hostname> and <port> is the hostname or IP address and port that the remote harvesting server runs on.

  2. The SHARED SECRET is used to ensure proper authentication of the remote server by the application server for Over the Web (Cloud) remote harvesting servers. It is a string and must match the M_AGENT_SHARED_SECRET assigned to the remote harvesting server as defined in the agent.properties configuration file. Details about web based configuration is below in the Cloud-based Application Server and Shared Secret section.

Please refer to the installation instructions for more details and special instructions for MetaKarta installations in the cloud.

The M_AGENT_SHARED_SECRET also acts as an identifier, so it must be made unique for a given application server. I.e., each remote harvesting agent must have a unique M_AGENT_SHARED_SECRET. The produce does not use the agent name for anything except for display in the UI.

  1. A DEFINITION

  2. You may also specify:

  3. MAX MISSED HEARTBEATS -- to specify the number of missed hearbeats or regular contract from a remote agent before it is considered disconnected

MetaKarta will send out an email notification when a harvesting server goes down, you should specify the MAX MISSED HEARTBEATS. Notification will be sent once the number of missed heartbeats (duration defined as the Heartbeat frequency) is reached, assuming email notification is configured properly.

  1. COMPRESS DATA -- to use data compression for the communication between the servers

  2. Set as Default -- To make this remote harvesting server the default when creating models.

  3. You may click SHOW USAGE to see the operations which executed on the selected server.

  4. Click Save.

When harvesting using a remote bridge server, one would perform the same steps as for any other harvesting activity with the exception selecting a (remote) Server name in the pull-down.

Examples

Sign in as Administrator and go to MANAGE > Servers.

You may determine the MIMB-OEM patch level in the Version column for each remote harvesting agent and the local (Default) server.

Now, select the line for the Default Server and click Show Usage.

Graphical user interface, text, application Description automatically generated

You may now pick this remote agent when creating or updating an imported model.

Explore Further

Upgrade

The Upgrade operation allows you to apply a software patch to the server from the UI. Each patch is in the ZIP format and is a collection of files and directories organized in the same manner as the home directory of the application server.

The most critical patches are officially delivered as cumulative patches.

You should inspect the currently running Operations and either let them finish or STOP them before the upgrade.

You may disable all schedules without deleting them by selecting the schedules you wish to set in the list and right-clicking.

Graphical user interface, text, application Description automatically generated

MIMB OEM Cumulative Patch Upgrade

Contains patches for all import/export bridges, in the format:

MIMB-OEM-CumulativePatch-1010-20200422.zip

These cumulative patches include updated import/export bridge components which will be automatically deployed in the local MM server, as well as in any connected remote harvesting servers.

Steps

  1. Sign in as a user with at least the Application Administrator capability global role assignment.

  2. Go to MANAGE > Servers in the banner.

  3. Confirm that all the remote harvesting agents are properly connected.

  4. Click on Upgrade.

  5. Browse for the patch package.

If you cannot find the location using the Browse function you must configure (as part of the installation) the available paths to present to users. More details may be found in the deployment guide.

  1. Click UPGRADE.
Examples

Sign in as Administrator and go to MANAGE > Servers.

Confirm that all the remote agents are properly configured.

Click on Upgrade.

Browse for the patch package.

If you cannot find the location using the Browse function you must configure (as part of the installation) the available paths to present to users. More details may be found in the deployment guide.

Click Upgrade.

A picture containing graphical user interface Description automatically generated

The Version date is now updated.

The date displayed for each server is the date defined in the last line of the MIMB-OEM-ReadMe.txt in each server which corresponds to the latest MIMB OEM cumulative patch applied.

Remote harvesting agents (servers) of type "Over the web" will experience a delay in displaying the Version date after a patch update as the remote harvesting agents only update the application server for new operations (like the patch) every 40secs.

MIMB Third-Party Download

Please refer to the Downloaded Third-Party Software section in the MIMM Deployment Guide.

Cloud-based Application Server and Shared Secret

When placing the MetaKarta Application Server on the cloud, you will generally need to place remote harvesting servers on premises in order to harvest metadata locally that are not accessible from the cloud. Obviously, an organization would not want servers outside the organization's on premises network to be able to invoke a harvesting server on premises. Thus, in the Over the Web (Cloud) mode, the harvesting is invoked according to a schedule on the harvesting server (not by the cloud-based Application Server) and the result is pushed up to the cloud.

Now, to ensure that no one may launch an attack on the Application Server in the cloud and pushing invalid metadata requests, both the application server and the on premises harvesting server use a shared secret between the cloud-based application server and the on premises harvesting server. In this scenario, both the URL in the UI and Server M_AGENT_SHARED_SECRET= in the agent.properties file of the on premises harvesting server must match before such a push of metadata is recognized or allowed.

Please refer to the installation instructions for more details and special instructions for the setup of the on premises harvesting server.

Example

  1. Specify the Type of on premises harvesting server to be Over the Web (Cloud).

  2. Enter a meaningful name in the Name field. Note, this name is what will appear when one is selecting the server to harvest from.

  3. Update the SHARED SECRET with the shared secret, in this case "SharedSecretLKDFLK*(L".

Graphical user interface, application Description automatically generated

  1. More details may be found in the deployment guide to update the agent.properties file of the on premises harvesting server with the same shared secret:

*M_AGENT_SHARED_SECRET = SharedSecretLKDFLK(L

As well as the URL of the application server.

Graphical user interface, text, application Description automatically generated

Now the server is working.

The M_AGENT_SHARED_SECRET also acts as an identifier, so it must be made unique for a given application server. I.e., each remote harvesting agent must have a unique M_AGENT_SHARED_SECRET. The product does not use the agent name for anything except for display in the UI.