Platform Framework
R24 AMR | Min(s) read

Configuration Validation

The sanity check application helps you to diagnose the cause of an issue and decide on what is not optimal in a Temenos Transact java deployment. As per the fail fast principle, it should ensure that the application and resources are coherent before running Temenos Transact. It provides information about components involved and highlights possible misconfigurations based on a set of rules. This section provides details on the process workflow, sanity check REST API, and common configuration for basic authentication.

You can access these information within an online dashboard using the http://localhost:8080/TAFJSanitycheck/dashboard.xhtml URL and through a REST API with the http://localhost:8080/TAFJSanitycheck/resources/configuration base URL.

A text report is generated under TAFJ_HOME/log/sanitycheck.log.

Many components and resources are involved in a deployment and different type of errors could occur with more or less important consequences as listed below:

  • Error preventing the application server to start and / or application to deploy and the system is not available.
  • Error where application server starts and deploys application but Temenos Transact is not or partially available.
  • Error where application is up and running but behavior is altered after a certain time.

The sanity check provides a tool to run:

  • A cartography of:
    • TAFJEE_EAR file to display current TAFJEE configuration
    • Application server deployment to display current resources configuration
  • A validation if:
    • Definition at ear file level matches with the definition application server level
    • Application, server and resources are working correctly all together
  • A proposition of fix and tips when validation warning or errors are raised.

The dashboard is made of three main panels:

Panel Represents Screen Capture

1

Application configuration with the view to channels, MDBs and EJBs.

2

Application server configuration with the data sources, JMS objects, threads pool, timeouts and JVM parameters.

3

Validation of the configuration, with validations events and suggestions about how fixing the eventual misconfigured resources or parameters.

Process Workflow

The following flowchart represents the workflow of creating a dashboard.

The first step of the process is the parsing and reporting of TAFJ ear file, which is the main component involved in a Temenos Transact java enterprise deployment. This component is the glue between client applications—Temenos Transact and Browser, TCIB, TW and so on. It handles incoming requests, passes them to Temenos Transact and sends back responses. The communication model used is JMS.

The TAFJ ear file defines the MDBs to handle JMS messages and EJBs to invoke Temenos Transact. There is a one on one relationship between a MDB and EJB, which is called as a CHANNEL. The TAFJ distribution provides a default ear file for each application server supported. It defines some default communication channels and their parameters—formatter, OFS source and timeout, thread pool and so on.

MDBs are defined within TAFJJEE_MDB.jar and EJBs in TAFJJEE_EJB.jar with deployment descriptors.

This parsing is available as a standalone application, which is helpful to run application analysis for a non-deployed ear file or draw comparison between different ear file versions.

The ear file parser is available as a standalone application, to append the ear file configuration in a console. It could be invoked from the TAFJ shell EarFileParser [-log] /path/to/ear/file [{JBOSS,WAS,WEBLO}]

The parameters are as follows:

Parameter Description

Log

Optional parameter to append the ear file report to TAFJ_HOME/log/sanitycheck.log

Ear file path

Mandatory parameter, which specifies the full path to the ear file, including the ear file name, that is /$TAFJ_HOME/appserver/ TAFJJEE_EAR.ear

Application server provider

Optional parameter to generate the report for a specific provider. The valid values are:

  • JBOSS
  • WAS
  • WEBLO

The report contains all configurations, if not specified.

The EAR file parsing is available from R16 onwards as it is used against the compliant deployment descriptors of JEE 6 and above.

The EAR file parsing may fail, if you try it in releases below R16.

The second step of the process is the application server cartography, which provides a clear picture of the application server parameters and resources relevant for Temenos Transact java application.

The configuration details have to be extracted from the application server. The information to be extracted when available are:

  • Data sources and related parameters: jndi binding, URL, pool size and so on.
  • JMS resources and related parameters: jndi binding, queue depth and so on.
  • EJB and MDB parameters: timeout, pool size

TAFJ distribution provides a set of scripts to configure the supported application servers. These scripts help to create all resources—JMS objects, data sources and shared libraries, required by the TAFJJEE application.

The extraction mechanism depends on the application server provider. This mechanism must be run once scripts are executed and the application server is up and running.

The following table lists the extraction mechanism per application server. (subject to change in future application server version):

Application Server Extraction Mechanism

JBoss 6EAP and higher

JBOSS CLI (Command Line Interface) client

You need to get a connection to the admin server (default port is 9990) and the server must be up and running.

WebLogic 12c and higher

JMX client

Webpshere 8.5 and higher

JMX client

You need to get a connection on the SOAP port of the application server (default port is 8880).

For WebLogic and Websphere, the standard java management extensions api (JMX) can be used to retrieve the application server parameters. Since JBoss 6EAP and Wildfly, JMX does not provide the application server configuration and the proprietary command line interface api need to be used.

For JBoss and Websphere, the dashboard defines a text box pre-configured with the default application server port to run the extraction. You need to change this value according to the port offset defined for the server, that is the default JBoss management port.

The application server supported at present are:

  • JBoss 6EAP / 7EAP / 7.1EAP
  • WebLogic 12.1.3 / 12.2.X
  • Webpshere 8.5.X / 9.X

Higher versions of the application servers should be supported if application server providers do not modify their API to publish configuration information.

The following tafj properties can be used to override default application server client parameters.

Properties Default value

temn.tafj.sanitycheck.management.hostname

localhost for Jboss and Websphere.

This property is not used for WebLogic.

temn.tafj.sanitycheck.management.port

9990 and 8080 for JBoss and Websphere, respectively.

This property is not used for WebLogic.

temn.tafj.sanitycheck.management.user

Null.

The values is to be defined when websphere secured JMX connector is used.

temn.tafj.sanitycheck.management.user.pwd

Null.

The values is to be defined when websphere secured JMX connector is used.

The last step of the process is to run validation tests against the collected information to ensure that:

  • No missing resources which are required at application server level
  • Classpath is correctly configured and Temenos Transact code is available
  • Pool size and timeout are coherent
  • Memory setup is coherent with the expected number of sessions

Based on the channel definition and application server configuration, a rule engine validates the coherence between all these parameters. It executes a set of pre-defined validation rules with different types and generates validation events. An event is associated to the severity (DEBUG, INFO, WARNING, ERROR) and eventually to a fix proposition. You can associate a rule to a channel or global to the deployment (global memory setup).

The following table lists the different types of validation rules you need to adhere to. These types are not fixed and can be extended in case of need.

Criterion Rules

Resource
  • Ensure that the related JMS queues and data sources are correctly defined at application server level for each channel.

Classpath
  • Ensure that the Temenos Transact code (OFS.BULK.MANAGER) and existing MDB formatter are available.
  • Ensure that the correct xml parser is used. If xmlparserv2.jar is unavailable in the classpath, the proprietary oracle DocumentBuilder may be used.

Memory
  • Ensure that the memory setup is correct to run the expected number of sessions (based on the sum of all pool size for all channels).

Pool

Ensure coherence among thread, component pool and data source pool with the following parameters.

  • MDB thread pool >= MDB pool to ensure there is enough thread to handle the expected number of concurrent MDB.
  • MDB pool <= EJB pool to ensure there is enough EJB to handle the expected number of concurrent MDB.
  • EJB pool <= DS pool to ensure there is enough data source connection for the channel.
  • Total EJB pool + batch channel pool <= DS pool to ensure there is enough data source connection to cover the maximum number of requests.
  • Phantom listener pool >= number of AUTO / START tSAs to ensure that all services can be started through ExecQueue.

Timeout

Ensure coherence among components timeout with the following parameters.

  • MDB Timeout >= EJB timeout to ensure that the MDB has the highest timeout of the chain
  • EJB timeout >= OFS timeout to ensure that the EJB does not timeout before the OFS expected timeout.
  • DB timeout >= OFS timeout to ensure that the query does not timeout before OFS timeout. This aims to provide a sufficient time to process Temenos Transact components (enquiry, versions, etc.).
    OFS timeout does not interrupts database or any IO related activity. However, you can reverse this rule by setting temn.tafj.sanitycheck.vmodel.validation to true.
  • OFS timeout >= DB timeout to ensure any database long running query is interrupted within the OFS timeout boundary.
  • Ignore stuck thread to ensure that “ignore stuck thread” parameter is defined for the Phantom channel. This is specific to WebLogic.

Data source
  • Ensure that the locking data source is not part of the transaction in case of JDBC locking.

    • It is specific data source parameters validation.

Database
  • Ensure that the java stored functions loaded in the database match the date provided with the current runtime.

The validation result is displayed in the Validation panel.

The following table lists the available filtering options with corresponding screencaptures.

Filter Option Screen Capture

Event category

Event severity

Channel or Server

The column next to the channel column displays detailed information about the rule parameters.

In the above screen capture,

  • Queues and data sources are involved in the RESOURCE validation.
  • Corresponding pool and timeout parameters for each component in the channel are involved in the POOL and TIMEOUT validation.

In case of WARNING or ERROR the Help tab displays some tips and fixes for the event (MEMORY validation EVENT with SEVERITY WARNING).

Example

The validation event reports the following, which are detected by the rules:

  • There can be up to 210 concurrent sessions on the server
  • The current memory setup for the JVM heap size is 1G.

The memory setup is insufficient and considering the load or job executed by all 210 sessions, the required memory size estimated is 10G.

[JVM heapSize = 1000MB - Maximum number of sessions =210 - Memory required =10500MB]

The Help tab provides the following explanation about this event:

The JVM max heap size is undersized to handle the maximum number of sessions for all channels

The proposed fix with a link to a screenshot is Review JVM Xmx parameter

POOL validation EVENT with SEVERITY ERROR.

The validation event reports the following, which are detected by the rules:

  • There can be up to 20 concurrent thread for this channel
  • 15 MDBs available from the pool
  • 220 database connections

[maxMDBThread=20, maxMDBPoolSize=15, maxEJBPoolSize=N/A, maxDSPoolSize=220, maxLockingDSPoolSize=0]

The application server configuration related pool is also highlighted in red.

The associated channel will not behave as expected because of this misconfiguration.

The Help tab provides an explanation about the reason of this rule validation failure.

The MDB pool size can be undersized to run the expected number of tSA.

Review the MDB pool size for this channel, refer to the appropriate pool size in the EJB view, @see Administration/Configuration/Container/EJB3/BEAN POOLS/Max Pool Size

Based on the total number of active tSA on the system, the rule detected that there is insufficient MDB to handle them. A fix suggestion would be to review the MDB pool size for this channel. The link to the associated application server parameter and related screencapture are provided.

In case of generic or technical error like missing resource, classpath misconfiguration, java stored function mismatch and so on ,a tip is provided in the event and a link to TAFJ documentation is proposed as the fix requires following step by step instructions.

The application server extraction covers most of the common configurations. However, depending on the application server configuration, certain resources can be seen as missing when they are not.

All information represented in the online dashboard can be found in the text report under $TAFJ_HOME/sanitycheck.log. This report need to be shared with the support team as it contains all information related to the configuration and the application version being used.

Sanity check REST API

The REST API provides same set of functionalities like the dashboard, which include:

  • Ear file configuration (MDBs, EJBs, Channels)
  • Server configuration (Data sources, JMS configuration, Thread pool, Timeouts, JVM parameters)
  • Validation events and fixes
  • Full report

The base service URL is: /TAFJSanitycheck/resources/configuration.

Get All MDBs 

@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("mdbs")

curl --request GET \
  --url http://localhost:8080/TAFJSanitycheck/resources/configuration/mdbs \

Get All EJBs 

@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("ejbs")

curl --request GET \
  --url http://localhost:8080/TAFJSanitycheck/resources/configuration/ejbs \

Get All Channels 

@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("channels")

@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("server")

curl --request GET \
  --url http://localhost:8080/TAFJSanitycheck/resources/configuration/server \

The server management port can be passed through an optional query parameter. If the port is not specified, the default value will be used. The secured parameter need to be specified in a websphere context to use the RMI connector rather than the default SOAP connector.

For example,

@QueryParam("port") @DefaultValue("-1") 
@QueryParam("secured") @DefaultValue("false") 

curl --request GET \
  --url 'http://localhost:9081/TAFJSanitycheck/resources/configuration/server?port=2810&secured=true' \

@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("validation")

curl --request GET \
  --url http://localhost:8080/TAFJSanitycheck/resources/configuration/validation \

Same optional query parameters could be passed to access the server configuration.

@QueryParam("port") @DefaultValue("-1") 
@QueryParam("secured") @DefaultValue("false") 

curl --request GET \
  --url 'http://localhost:9081/TAFJSanitycheck/resources/configuration/validation?por port=2810&secured=true' \

@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("report")

curl --request GET \
  --url http://localhost:8080/TAFJSanitycheck/resources/configuration/report \

Same optional query parameters could be passed to access the server configuration.

@QueryParam("port") @DefaultValue("-1") 
@QueryParam("secured") @DefaultValue("false") 

curl --request GET \
  --url 'http://localhost:9081/TAFJSanitycheck/resources/configuration/report?por port=2810&secured=true' \ Securing web applications

The TAFJEE.war and TAFJRestServices.war files provide access to several functionalities that might need a protected access:

  • TAFJEE/ExecuteServlet posts JMS message to the ExecQueue
  • TAFJEE/monitoring accesses the TAFJ technical monitor
  • TAFJRestServices /resources/ofs processes OFS request through webservice
  • TAFJRestServices/resources/callAt processes CALL_AT through webservice

A sample configuration is available to add a BASIC Authentication (role, user and password) to these applications. It consists of a common configuration part at webapp level and in a specific configuration part at webapp and application server level depending on the appserver provider.

Basic Authentication common configuration

Comment out in the web application /webapp/WEB-INF/web.xml the section related to security at the end of the file.

Sample below is extracted from TAFJEE.war but same applies with TAFJRestServices.war.

This sample illustrates how to add a basic authentication for all URLs under TAFJEE context. It means only authenticated users with role TAFJAdmin could access these URLs. It could be refined to have a security role per URL.

<!-- Security Stuff A template configuration to secure the webApp -->
	<security-constraint>
		<web-resource-collection>
			<web-resource-name>TAFJEE</web-resource-name>
			<url-pattern>/*</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>TAFJAdmin</role-name>
		</auth-constraint>
	</security-constraint>
	<security-role>
		<role-name>TAFJAdmin</role-name>
	</security-role>
	<login-config>
		<auth-method>BASIC</auth-method>
		<realm-name>TAFJRealm</realm-name>
	</login-config>

The basic authentication for JBoss involves the following:

In the web application /webapp/WEB-INF/jboss-web.xml, you need to add the following.

<!-- A template configuration to secure the webApp -->
<security-domain>TAFJRealm</security-domain>

For Jboss EAP7 deployment, you need to add a security domain in the security domains section of the standalone.xml file under server/standalone/configuration.

<security-domain name="TAFJRealm" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="${jboss.server.config.dir}/tafj-users.properties"/>
<module-option name="rolesProperties" value="${jboss.server.config.dir}/tafj-roles.properties"/>
</login-module>
</authentication>
</security-domain>

You need to create files in server/standalone/configuration/ tafj-user.properties and do the following:

  • Add a user and password, that is tafj=password

    • server/standalone/configuration/tafj-roles.properties

  • Add a role TAFJAdmin and associate it to tafj user tafj=TAFJAdmin

You could refer to https://community.jboss.org/wiki/JBossAS7SecureMyWebAppHowDoI?_sscc=t

As an alternate way, you can create user under Application Realm, from <JBoss_Home>/bin with the script add-user.bat or add-user.sh, for the role TAFJAdmin. A sample is shown below

The basic authentication for WebLogic involves the following:

You can provide comments in the section related to security at the end of the file in web application /webapp/WEB-INF/WebLogic.xml.

<!-- A template configuration to secure the webApp     -->
<security-role-assignment>
       <role-name>TAFJAdmin</role-name>
       <principal-name>TAFJAdmin</principal-name>
</security-role-assignment>

You can add a security realm through WebLogic console or use the default myrealm and add the following sequentially.

Add Property Screen Capture

TAFJAdmin group

User tafj

TAFJAdmin to user tafj

The basic authentication for Websphere involves the following:

No specific change applies to webapp.

The Websphere profile must be secured to perform the following configuration. You need to enable administrative security and application security.

For deployment, you need to create user and group and map TAFJAdmin role defined at webapp level to TAFJAdmin group.

Copyright © 2020- Temenos Headquarters SA

Contact Us

knowledge@temenos.com

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