Event Analytics for Adabas: Technical Concepts : Logical and Physical Architecture : Physical Architecture
Physical Architecture
The figure above describes the servers involved in the solution:
*Mainframe: platform where Adabas and Adabas Review execute.
*Server#1 (Integration): implements the integration functionality, basically receiving Adabas events and forwarding them to the Event Processing Server platform on Server#2.
*Server#2 (Event Correlation): collects the events on Messaging Server JMS queues, performs the correlation in terms of the current auditing trails and triggers accumulation of statistics on RDBMS or alerting via SMS or mail.
*Server#3 (Presentation/Alerting): the platform for holding dashboard servers, where end users will connect for monitoring the dashboards provided.
Some premises:
*Security considerations:
*File transfer from mainframe to Linux/ UNIX/ Windows will connect to and will be authenticated by the Transfer Server with its own methods. Although this is not a requirement, no data encryption is recommended between mainframe and Linux/ UNIX/ Windows since this would introduce quite a lot of overhead in the process.
*Dashboard login authentication: this can be implemented with local authentication, LDAP and SSO, depending of the customer requirements and product capabilities.
*Other input sources to the Event Processing Server: the solution can manipulate other sources of information (e.g. log files from other applications) if that makes sense in terms of correlation for the monitored audit tracks. These sources will be grabbed using the existing standard Event Processing Server adapters.
*Alerting: Generation of SMS and email alerts depends on the basic Event Processing Server adapters and external services not listed specifically on this architecture (eg, WebServices for SMS sending).
In terms of platform sizing we can consider:
*Expected load: in the worst case scenario it is expected that Adabas Review would collect ALL CLOG records from production databases from where at least one auditing track is active. This can be many millions of records per day. But in reality not all CLOG records need to be processed, since not all Adabas files are in fact involved in the audit trails. Some filtering techniques can be applied in mainframe side to reduce the amount of records sent to the Event Processing Server.
*Typical sizing:
*Server#1 (Integration): 4 Cores/16Gb RAM.
*Server#2 (Event Correlation): 16 Cores/64 Gb RAM.
*Server#3 (Presentation/Alerting): 4 Cores/16 Gb RAM.

Copyright © 2014 Software AG, Darmstadt, Germany.