Platform Framework
R24 AMR | Min(s) read

TAFJEE Micro

TAFJJEE Micro is an alternative to the original TAFJ EE solution, which is based on the deployment of an EAR file. It regroups multiple artifacts that covers various needs like business processing, management operations, technical and functional monitoring, configuration, diagnostic, utilities, and so on. This section provides an overview, architecture and configuration of TAFJEE Micro.

Overview

By default, all online channels are present in the TAFJJEE_EAR deployment, 18 OFS sources are defined and must be bound to 18 pairs of JMS. The configuration is managed through deployment descriptors within the ear file.

The goal with Micro EE is to offer same functionalities but with a new deployment capability. It respects the micro-services architecture model, with single responsibility principle and latest deployment requirements in the cloud regarding dynamic provisioning and elastic scaling.

The base Micro EE architecture is as follows:

The Micro EE architecture defines one and only one online channel per deployment, considering the business services offered by TAFJ EE. The service parameters and enabled features are defined at runtime through configuration.

The available features are:

  • Online processing (OFS or CALLAT)
  • Background processing (Phantom)
  • tRun processing
  • Management activities (Sessions management, EJB warmup / tSA on startup, management topic).

The following table lists the MDBs, EJBs and configuration file in TAFJJEE_Micro.jar.

MDBs

EJBs

Configuration File

ManagementListener

Management

Jboss-ejb3.xml

OnlineListener

OFS

 

PhantomListener

CALLAT

 

 

tRUN

 

The minimal deployment descriptor (jboss-ejb3.xml) defines the proprietary Wildfly or Jboss configuration parameters to enable or disable and size services which need not be edited, unless a specific JMS broker is used, and can be ignored from end user perspective.

You can configure the application through the platform with environment variables, system properties, database configuration and so on. You need not amend the archive (deployment descriptors) at deployment time or following an update, unless a specific JMS broker is needed.

It allows you to control the running services, their dimensioning (pool size) and also the business parameters. The JMS resources to be defined at deployment level are also greatly simplified:

  • One pair of OFS queue (request or reply) for online processing
  • Phantom queue for background processing, which can be common to all deployments
  • Management topic for management activities

For Phantom processing in distributed environment, you need not define a local ExecQueue per environment. The dynamic message filtering allows the usage of a common shared queue for all deployments.

Targeted Architecture

The targeted architecture for the application layer is a cloud or containerised Wildfly or JBoss EAP deployment but it could also be deployed on a standard Wildfly or JBoss EAP installation on premises.

The Wildfly or JBoss EAP is required for the dynamic configuration capabilities it offers at runtime by injecting environment variables and system properties within server and application configuration.

The main configuration is automated with scripts (JBoss - CLI) and during runtime, the environment variables set at orchestrator level are resolved and injected to run the expected setup. There are different categories of parameters which are used at different level to wire the components together and configure the application.

The ActiveMQ JMS broker is deployed on a separate tier.However, you any other JMS broker to suit the requirement. The Wildfly AMQ internal broker is not used anymore since there is no need for a local Exec queue.

You need to do JMS configuration to deploy the Micro EE application. Each deployment defines the following generic JMS resources which are bound at runtime to common or specific ActiveMQ resources.

JMS Resource

Bound to

java:/queue/t24OnlineQueue

Specific Queue

java:/queue/t24OnlineReplyQueue

Specific Queue

java:/queue/t24EXECQueue

Common Queue

java:/topic/t24ManagementTopic

Common Topic

To add additional resources like CALLJEE, you can use the CLI script.

You can share the phantom queue across all instances by defining a message selector. You can assign a unique ID per server to the environment variable phantom_selector. This variable is used at server startup to define a unique message selector for the PhantomListener MDB.

When sending a message to the shared ExecQueue containing a JMS property PhantomSelector, the listener with the corresponding phantom_selector message filter will treat the message. In case of message with no PhantomSelector, any of the registered PhantomListener will consume the message.

When the environment defines a phantom_selector environment variable, any services targeting the Exec queue will set it as a JMS message property to ensure processing on the same server instance.

Configuration

You need to define two different property types to configure the deployment and application. The properties used to configure the deployment and application must be provided as environment variables and as part of TAFJ configuration, respectively.

To distinguish between these two types a different formalism is used.

The deployment configuration properties respect the DEPLOYMENT_CONFIG / deployment_config formalism. They are used to configure links between application tiers (server, DB or broker) and also to enable and configure the application services.

You can completely configure the connection with the database through environment variables.

Property

Description

Default Value

DB_URL

Indicates the DB connection URL.

None

DB_USERNAME

Indicates the DB user.

None

DB_PASSWORD

Indicates the DB password.

None

DB_DRIVER

Indicates the DB provider. This valie must match the jboss jdbc-driver name defined in CLI script. The valid values are:

  • h2

  • sqljdbc

  • ora12c

None.

DB_POOL_SIZE

Indicates the datasource maximum concurrent connection number.

None

You can completely configure the connection with the external ActiveMQ broker through environment variables.

Property

Description

Default Value

AMQ_URL

Indicates the broker connection URL

None

AMQ_USERNAME

Indicates the broker user

None

AMQ_PASSWORD

Indicates the broker password

None

You can connect to a Websphere MQ broker with the following environment variables.

Property

Description

Default Value

MQ_HOSTNAME

Indicates the broker connection URL

None

MQ_PORT

Indicates the broker user

None

MQ_QUEUE_MANAGER

Indicates the broker password

None

MQ_CHANNEL

Indicates the broker channel

None

You can use the following environment variables to define the physical queue mapping at broker level with the fixed JNDI names defined at MicroEE level. The mapping for online processing should be different per environment or channel definition.

The Phantom queue and management topic are shared and should be the same on each environment.

Property

Description

Default Value

ONLINE_QUEUE

Indicates the physical name of the online channel request queue

None

ONLINE_REPLY_QUEUE

Indicates the physical name of the online channel reply queue

None

EXEC_QUEUE

Indicates the physical name of the Phantom channel queue

None

MANAGEMENT_TOPIC

Indicates the management topic physical name

None

These properties define the available services and their configuration.

Property

Description

Default Value

channel_type

Indicates whether the online processing is OFS or CALLAT. It is the link between TransactedMDB and OFSProcessingBean or CallAtProcessingBean.

The valid values are ofs and callout.

ofs

online_active

Indicates if the online MDB (TransactedMDB) is enabled and listening to AMQ_ONLINE_QUEUE.

The valid values are true and false.

None

max_online_session

Indicates the online MDB thread pool (maximum concurrent messages).

It is an integer parameter.

None

phantom_active

Indicates if the phantom MDB (PhantomListener) is enabled and listening to AMQ_EXEC_QUEUE.

The valid values are true and false.

None

max_phantom_session

Indicates the phantom MDB thread pool (maximum concurrent messages).

It is an integer parameter.

None

phantom_selector

Indicates the message selector which applies to the Phantom MDB. If a JMS message contains a JMS property “PhantomSelector” it will be treated if phantom_selector=PhantomSelector.

This value is also set as ‘PhantomSelector” when posting message to AMQ_EXEC_QUEUE. This value should be unique per environment.

It is a string parameter.

None

Processing

Example

OFS
  • channel_type=ofs
  • online_active=true
  • max_online_session=10

channel_type is optional since the default value is ofs.

CALLAT
  • channel_type=callat
  • online_active=true
  • max_online_session=5

channel_type is mandatory to infer CALLAT processing instead of OFS.

Phantom
  • phantom_active=true
  • max_phantom_session=20
  • phantom_selector=server1

The application configuration properties respect the application.config / applicationConfig formalism.

The property formats used used to configure the application, services behaviour and processing parameters are:

Property Format

Used In

application.config

TAFJ configuration

applicationConfig

Deployment descriptors to configure MDBs or EJBs.

A TAFJ property defined as an environment variable takes precedence on property defined in TAFJ configuration (database). The bean (MDB or EJB) properties can also be added to the TAFJ configuration to avoid duplicating them in all environment.

A sample configuration file can be found in the release pack under:  $TAFJ_HOME/appserver/micro/deployment/example/channel-configuration, replicating the configuration present in TAFJJEE_EAR deployment descriptors.

You need to define a service name per service type and apply the same as a property prefix to distinguish the corresponding property applicable for each service in the configuration.

Service Type

EJB

Default Service Name

Online processing

OFSProcessingBean / CallAtProcessingBean

None

You can leave it blank or set through property ‘channel_name’

For example, channel_name=tws

Phantom processing

PhantomListener

phantom

tRun processing

TRunProcessingBean

trun

Management activities

TAFJManagementBean

management

Examples to configure a channel for:

Processing

Example

CALLAT (CALLAT processing) without service name
  • channel_type=callat
  • ofsSource=JAVA.FRAMEWORK
  • ofsTimeout=30

BrowserWeb (OFSProcessing) with service name
  • channel_name=browserweb
  • browserweb.ofsSource=BROWSERTC
  • browserweb.ofsTimeout=300
  • browserweb.maxJmsRedeliveryAttempt=0

Phantom channel
  • phantom.isJTA=true
  • phantom.jtaTimeout=600

tRun channel
  • trun.trunTimeout=60
  • trun.allowedCommand=\bA.JBC.ROUTINE\b|\bANOTHER.JBC.ROUTINE\b

Management EJB
  • management.ejbWarmup=OFSProcessingBean=2
  • management.tsaStart=3
  • management.logoffBatchSessionOnDestroy=true
  • management.logoffOnLineSessionOnDestroy=false

Copyright © 2020- Temenos Headquarters SA

Contact Us

knowledge@temenos.com

Published on :
Monday, May 27, 2024 5:10:15 PM IST