iWay Service Manager

In this section:

This section describes new features for iWay Service Manager (iSM) in Version 6.1.7. For a list of resolved cases, see the iWay Service Manager Release Notes.


Top of page

x
iWay Functional Language

To enable input string matching capabilities against a regular expression or based on values in a properties file, the following iWay Functional Language (iFL) calls have been introduced in iSM Version 6.1.7:

For more information on using the _match() and _propertymatch() functions, see the iWay Functional Language Reference Guide.



x
_match() Function

The _match() function matches an input string against a regular expression. A successful match is returned as true, and an unsuccessful match is returned as false.

The _match() function uses the following format:

_match(input,pattern)

input

string

The input string to be matched against the regular expression.

pattern

string

The regular expression pattern.



x
_propertymatch() Function

A properties file contains key=value pairs consisting of a regular expression and a value. An input string is matched against the patterns in the properties file, and the value associated with the first pattern to match the input is returned.

The properties file is loaded once, cached for the channel, and is not reloaded for each use. If any changes are made in the properties file, the channel must be restarted to reflect these changes.

The _propertymatch() function uses the following format:

_propertymatch(file,input,[,default [,control [,encoding]]]

file

path

Path to the properties file. The suffix is optional.

input

string

The candidate to be matched against the regular expressions in the properties file.

default

string

The value to be returned if none of the patterns are matched by the candidate input string.

control

keyword

Keyword to control operation:

  • check. Check for modification.
  • keep. Do not check for modification.

encoding

string

IANA encoding of the properties file.

The properties file consists of one or more regular expressions (keys), each with an associated value. Standard properties file comments (lines starting with #) and blank lines are allowed. Continuation lines are not supported.



x
Special Registers Ordered Evaluation

iSM Version 6.1.7 introduces the ordered evaluation of Special Registers (SREGs) as they are defined by the SREG Service (com.ibi.agents.XDSREGAgent). This guarantees the evaluation order from top to bottom as listed in the definition. This enables earlier registers that were set to be used in the definition of later registers within the same Service object.

In the following example, the registers are evaluated in the order they are defined. If SREG(one) evaluates to 1900, then SREG(two) will evaluate to 1901 and SREG(three) will evaluate to 1902.

one

_xpath(/root/coms/@port)

two

_sreg(one)+1

three

_sreg(two)+1

For more information, see the section for SREG Service (com.ibi.agents.XDSREGAgent) in the iWay Service Manager Component Reference Guide.



x
HTTP Sessions Management

In HTTP, a session is a sequence of network request-response transactions. A session may encompass a group of console screens or web interactions for a specific purpose. In transactional HTTP, such as REST or web services, a session may represent one or more request-response activities, such as sending a group of related shipping operations.

As of iSM Version 6.1.7 and higher, applications can associate session information with an HTTP interaction. The session information is not actually carried between the client and the server. Rather, a token is assigned by iSM, which is carried between interactions. The token identifies the current session, much as a transaction ID represents the action of a single transaction within the session. By not carrying the session information between interactions, security is enhanced and network traffic is reduced.

Session information is carried in Special Registers (SREGs), which are created by the application and available in the later steps where they can be referenced and changed as required. The session SREGs are carried in a SREG scope called session. The session scope is not a namespace, although namespaces can be used within the session.

The session key is exchanged with the client by use of the standard JSESSIONID cookie, so management of the session involves dealing with the treatment of this cookie.

The session key is exchanged with the client by use of the standard JSESSIONID cookie, so management of the session involves handling the treatment of this cookie.

nHTTP Listener Session Support

To enable the use of sessions by the nHTTP listener, set the Session Support parameter to true, as shown in the following image.

HTTP Session Register Scope

Setting the session information for an application is configured by using the Special Register Setting Service (com.ibi.agents.XDSREGAgent).

From the Scope of variable drop-down list, select HTTP Session {session}, as shown in the following image.

You must have the session support configured for the channel in order for the register to automatically appear in the next client interaction.

Session Invalidator Service (com.ibi.agents.XDHttpSessionInvalidator)

The Session Invalidator Service (com.ibi.agents.XDHttpSessionInvalidator) can be used in a process flow to invalidate the current session. This deletes all information in the session and prevents the session from being exchanged in subsequent client-server interactions.

For more information on associating session information with an HTTP interaction, see the iWay Service Manager Protocol Guide.


Top of page

x
Ordered Listener

A common application requirement is to present messages to a channel for processing in an order that is not directly related to the order of their arrival at the prior channel. For example:

Underlying these types of requirements is a system that receives in some intermixed sequence, is charged with not losing any messages, and desires to process the incoming messages in parallel. Parallelism loses the input ordering. However, single threading has an adverse impact on performance.

The ordered listener is an iWay Service Manager (iSM) channel that alleviates these concerns of parallelism, retaining the required order, and collecting messages for a specific purpose for dispatch to the next channel. Messages can be dispatched as they become available, while retaining the order, or as an ordered group when the final message of the group is recognized. With the exception of the ordering facility, an ordered queue is similar to the commonly used internal queue, and it retains the characteristics of that type of channel. This includes support for low and high watermark tracking, passivation, inhibition, and so on.

For more information on ordered queue processing, see the iWay Cross-Channel Services Guide.


Top of page

x
iWay Service Manager Administration Console Settings

iWay Service Manager (iSM) is configured and monitored using the iSM Administration Console, which is a web-based user interface. This console can be configured using the Console Settings section, as shown in the following image.

iSM Version 6.1.7 introduces Console Tracing as an additional configuration option. This setting determines whether the iSM Administration Console participates in the standard tracing for the server. If set to On, then the console does participate. However, console tracing can be voluminous, and can therefore interfere with trace log analysis. The Console Tracing option is set to Off by default, meaning that the console only traces error and warning messages. You can set an individual trace level on the console using the Set command.

For more information on iSM Administration Console settings, see the iWay Service Manager User’s Guide.


iWay Software