Where Reflex is reacting to information outside of the native EMS regime, the two-way flow of events and commands are managed through Reflex's extensive Gateway module. By using simple screens, the Gateway module enables you to set-up the rules by which non-EMS messages will be converted. The template created will then be invoked whenever the specified message is seen by Reflex.
The process is simple. You identify the portions of the event message that you deem a 'match' to the event you want to convert. Then you identify the conversion rules (what you want to keep from the original message and what you want to be added) to create the new and unique EMS message.
You can have as many of these Gateway processes running as you wish, tailoring each to the specific application or applications that have messages you want converted.
Reflex 80:20 supports the following non-EMS events :
- Text (also 512 text EMS events)
- SNMP (Simple Network Management Protocol)
- API
- Status Agents
Once an event is converted, you can apply any of Reflex's automation tools to these 'tokenised' events in just the same way to define reactions, using the Reflex 80:20 React module.
For those applications that are generating good quality diagnostics but as text rather than in the proprietary EMS format, then there is also a Reflex 80:20 solution to this problem.
The issue with text messages is that if they are written directly to EMS unformatted instead of as a series of tokens as described in our EMS overview, then EMS recognises this and creates a default event on behalf of the originating process with identical token settings.
The event buffer includes the same event number; TANDEM.12.0 event 512 and no subject. This makes filtering this information at best an expensive processing exercise and sometimes it can be impossible.
Instead of sending this diagnostic information directly to EMS, the Reflex 80:20 Gateway facility can take receipt of the text messages and based on some preconfigured rules generate a fully tokenised EMS event in a nominated EMS collector instead. This event can then be routed to the Reflex 80:20 Reaction engines.
Consider the following simple example text messages :
Bank Of Insider: Interface $BOI25.#TERM1 ABORTED 140
Bank Of Insider: Interface $BOI25.#TERM1 RESTARTED
Bank Of Insider: Interface $BOI25.#TERM1 CONNECTED
We can create three different rules for this data.
Rule 1 – If the characters “Bank Of Insider: Interface” appear in positions 1 to 26 and the characters “ABORTED” appear in positions 42 to 48 then generate the event INSIDER.99.0 140 with the text as it is and a subject of whatever is in positions 28 to 40, i.e. $BOI25.#TERM1. This would process message 1.
Rule 2 – If the characters “Bank Of Insider: Interface” appear in positions 1 to 26 and the characters “RESTARTED” appear in positions 42 to 50 then generate the event INSIDER.99.0 999 with the text as it is and a subject of whatever is in positions 28 to 40, i.e. $BOI25.#TERM1. This would process message 2.
Rule 3 – If the characters “Bank Of Insider: Interface” appear in positions 1 to 26 and the characters “CONNECTED” appear in positions 42 to 50 then ignore this text message. This will ignore message 3, it is information and requires no further reaction processing.
If it is required, you can edit the text, deleting redundant information such as date and time and adding new data such as severity or the name of the originating process.
The text to EMS translation rules are built within the Reflex 80:20 GUI and require no programming expertise. If text messages arrive in the Gateway and there is no rule built, then an alert is generated and you can create and implement a rule for the new text without closing down the software.
The two new events (INSIDER.99.0 140 and INSIDER.99.0 999) are registered in the Reflex 80:20 database for you as part of the translation exercise and they can now be made available to all the Reflex 80:20 reaction modules.
As well as processing text from applications that are not instrumented for EMS there are two other common uses of the Gateway.
Applications sometimes generate EMS events of poor quality. They may include the subject of the event in the body of the description but not as a separate subject token. This means that if an Operations Management product wants to process this event and ascertain the name of the device affected by this error, then it has to parse the text. In this respect it is only slightly better than the original text message.
To illustrate this we can return to our earlier example:
If the message “Bank Of Insider: Interface $BOI25.#TERM1 ABORTED 140” was being raised as event INSIDER.99.0 140 rather than as text by the application and it had no subject, then we can use a print distributor to extract the event from EMS and send the template formatted text of this event to a Gateway process.....
EMSDIST TYPE P, COLLECTOR $0, FILTER IN99140F, TEXTOUT $RFGW
..... where it can be translated into a new event with a subject and then resubmitted into the Event Management System.
Careful use of this technique can significantly improve application management.
The other use of Gateway is to provide immediate EMS integration for those applications ported to the NonStop platform and which will run under the OSS personality. If the OSS process can be altered to write its log output to a nominated Guardian process, i.e. the Reflex 80:20 Gateway, then text to EMS rules can be built for these UNIX application text messages.
If the OSS application can only write to SYSLOG, then the EMS events generated by the OSS SYSLOG (TANDEM.143.0) can be retrieved, translated and resubmitted using the print distributor method described earlier.
Other Gateways
There have been instances in the past of Reflex 80:20 being used as an Enterprise Manager. The rationale has been that as the hardware is the most “available” technology in the network then it is a good place to site a management platform.
To meet this requirement, Reflex 80:20 is equipped with a variety of other gateways that will allow inbound SNMP traps and text messages sent via Async and Telnet linked devices to be routed to EMS and then on to Reflex 80:20 React engines.
Further information about these modules is available on request from Insider Technologies.
Hardware and software pre-requisites for the Reflex product are detailed below:
• HP NonStop (ServerNet or Integrity platforms)
• Guardian D38 Operating System (or above)
• TMF
• SQL runtime system (SQL/MP runtime), or alternatively, NonStop SQL product
• Pathway (TS/MP)
• TCP/IP
• Non-RDF/DRNET Audited Volume *
* It is recommended that Reflex is installed on a Non-RDF/DRNET Audited Volume. If this is a cause for concern, please contact Insider Technologies Ltd to discuss further.
Reflex is installed using a menu driven TACL macro for easy deployment. The macro will perform checks and output the results of each stage of the Reflex product install so that if problems are encountered they can be resolved easily.
Windows Platform for GUI Install:
• Modern Pentium PC Specification
• 32Mb on-board RAM
• 20Mb free hard disk space
• Minimum 17” monitor recommended
• Graphics Resolution: 1027 x 768 x 16 minimum
• Windows XP, Vista, 7
* For escalation of HP NonStop issues to enterprise management solutions, email or mobile SMS, a dedicated Windows box is required.