A migration approach from TIBCO BWPM3/nJAMS3 to nJAMS4

Update December 2017: TMNS is now Devoteam

What is nJAMS?

nJAMS is an abbreviation of the product from Integration Matters (a software vendor in Germany Hattingen) nJAMS stands for: Not Just Another Monitoring Solution. People from the TIBCO community will know this product as TIBCO BWPM, also known as BusinessWorks Process Monitor.

nJAMS architecture

Why should you consider nJAMS?

Let’s start with the main reasons why you should consider (an upgrade to) nJAMS 4. nJAMS 4 is monitoring tooling that, if implemented professionally, supports your organization in:

  • Bringing Dev and Ops together using Business Activity Monitoring (BAM) to provide business process insights for operations and monitoring driven development for faster time-to-market.
  • Providing a real-time end-to-end process monitoring solution which spans multiple integration platforms, enterprise applications and cloud services.
  • Facilitating communication between business and IT with new KPI reporting capabilities.

What is new in nJAMS 4?

  • Customizable Web UI for business users
  • Out of the box process performance reports as well as a Custom reports wizard
  • Clean and intuitive Web UI for IT users
  • Powerful query language
  • High-end storage engine (Elastic Search)
  • Rules-based monitoring of interface activity
  • significant performance and unlimited scalability enhancements

Seeing this list of new functionalities in nJAMS4, you might ask yourself the following questions:

  • Are you using TIBCO BWPM 3 or nJAMS 3 and want to go to nJAMS 4?
  • Is your organization running TIBCO BusinessWorks 5 Classic and is TIBCO BusinessWorks 6 on your Roadmap?

If the answer to at least one of these questions is yes, please hesitate no longer!!!

TMNS, as implementation partner of Integration Matters had the opportunity to try nJAMS 4, before the official release. What follows is a migration approach from TIBCO BWPM3/nJAMS3 to nJAMS4.

The current ESB landscape

First let me visualize an example of what your current ESB landscape might look like…

A current ESB landscape

TIBCO BusinessWorks applications might be configured with a dedicated EMS connection, which is established upon deployment of the application. No code has to be rewritten, just to connect to the dedicated EMS daemons. Making use of the nJams implicit way of monitoring. It doesn’t matter whether you are using exclusively the SAP, ADR3, iProcess, RDBMS, Axway, BW6, BPM, Mulesoft or Webapplications Client. All of these clients are loosely coupled by JMS making use of an IM standard LogMessage format. The DEV/TST/ACC environments might be pushing their nJAMS events asynchronously to TIBCO EMS daemon(s) in their own environment. The nJAMS 3 server is configured to use multiple JMS connections pointing towards DEV/TST/ACC environments and have multiple dataproviders running. Production environment is separated completely in most cases.

The existing nJAMS3 compared with nJAMS 4

Let’s compare the existing nJAMS 3 with nJAMS 4.

nJAMS3 compared to nJAMS4

*Heartbeating meachanism will only be visible in the nJAMS 4 GUI in combination with clients that have heartbeating mechanisms.

Before starting a migration from nJAMS 3 to 4, certain aspects need to considered:

  • What is the average release time for an application from DEV to PRD?
  • Is there a release calendar available?
  • Who are the main users of the nJAMS GUI and which tools use the nJAMS database?
  • What is the average delivery time for servers or VM’s?
  • What is the average time for network changes?
  • Who will be involved internally and externally?
  • Are the current users trained to use the new version?
  • What will be the next storage being used?
  • How about life cycle management, automation, support and maintenance?
  • How about versioning of configurations?
  • How to handle security, privileges and data collection on PRD environments?
    • Consider to migrate domain object permissions if there are specific permissions granted in BWPM 3 / nJAMS 3
    • Consider to migrate Extracts configuration. nJAMS Clients have to publish their configuration to nJAMS Server 4 once. This can be done by restarting nJAMS Clients as soon as nJAMS
  • Server 4 is up and running.
  • How to efficiently deal with storage on PRD environment?
  • What kind of data retention history will be maintained?
  • Are there existing nJAMS rules and privileges that need to be migrated?
  • Is there an existing Enterprise DataWareHouse (DWH) solution being used for longer than data retention history of nJAMS?
  • Will backup be considered?
  • What is the most logical place on the network and infrastructure to place these new servers?
  • Do we need reporting on process monitoring level?

Based on this information:

  • A planning can be made in what time frame an activity, release or phase takes place.
  • A planning can be made based on the release calendar of operations.
  • An impact analysis can be made for migration on development, daily operations and business analytics.
  • Stakeholders need to be involved in an early stage of the migration.
  • Multiple dates for training or periodic assessment meetings can be scheduled.

The migration approach in parellel state

The migration approach in parallel state

This approach describes:

  • Leaving the current servers with nJAMS 3 intact, so that development, daily operations and business analytics can continue with minimum impact.
  • Adding servers that are scaled for nJAMS 4 into your infrastructure, so that they run parallel to your existing nJAMS 3 servers.
  • Make a list of requirements for the new servers.
  • The datasource for monitoring configuration stays on database level.
  • The datasource for monitoring events shifts from database to elastic search.
  • Network changes need to be made for the new servers to be able to reach the designated environments.
  • Make use of the dedicated EMS daemons already in place, just create nJAMS 4 related Queues and Topics and use Bridges and/or Routes.
  • Configure nJAMS 4 to connect to the existing dedicated EMS server, but on their own Queues and Topics destinations.
  • If there are multiple EMS daemons per environment these can also be added.
  • Configure LDAP and SMTP according to existing LDAP and SMTP on nJAMS 3, let the users experience themselves by making the GUI available.
  • A time needed to compare the nJAMS 3 to the nJAMS 4 environments running in parallel.
  • If there are any Business Activity Monitoring dashboards using the nJams 3 database as a datasource, then these need to be converted so that the nJAMS 4 database is used.
  • Configure nJAMS 4 to point to the original Queues/Topics.
  • Remove nJAMS 4 Queues, Bridges and Routes.
  • Phase out the old nJAMS 3 servers when completely satisfied with the new environment.

The datastreams between nJAMS clients and the nJAMS servers.

With JMS properly configured, one can expect the same data in the nJAMS 4 environment as well. Apply the same properties for queues and topics already in place. 

Table: Queues and topics nJAMS4

Queues on TIBCO EMS:
Table: Queues on TIBCO EMS

Bridges on TIBCO EMS: 

Bridges on TIBCO EMS

JMS configuration on nJAMS 4:

JMS configuration on nJAMS 4

JMS configuration on nJAMS 4

Datastreams Clients and Servers (*it is recommended to run nJAMS Server and Elasticsearch Node(s) / Cluster on separate machines)

nJAMS 3 with the TIBCO BusinessWorks 6 Client

nJAMS 4 with the TIBCO BusinessWorks 6 Client

nJAMS 4 with the TIBCO BusinessWorks 6 Client:

nJAMS 3 with the TIBCO BusinessWorks 6 Client

More information about this product?

Please refer to: https://www.integrationmatters.com/

Images and File descriptions Copyright Faiz and Siegeln Software GmbH. 



Andy Chan