This section describes system automation and health checking for the SAP system.
An SAP system has many components, and operation of these components is complex. According to several surveys a significant percentage of unplanned outages is caused by operator errors.
As more SAP systems are added, the need for automated operations becomes even greater. Simplifying the operation of the SAP system can help you meet your service level agreements. It can also help you contain costs while more efficiently using your operations staff by automating error-prone repetitive tasks.
Usually, automation software is combined with switchover and cluster products. While switchover and cluster software is needed for individual resource monitoring and handling, automation software can be seen as higher level of system control. System automation might span:
· Multiple business applications
· SAP systems
· Other products
· Different platforms.
The impact of an unplanned incident can be further mitigated by rapid system restart and a high degree of automation. Some products provide additional features to enable automated disaster recovery.
Automation software can be divided into the following categories:
· Script-Driven Automation Software
Some automation software is script-driven. Scripts are invoked when an event occurs such as a resource becoming unavailable. Such events are triggered by the underlying cluster and switchover software.
Although scripts are quite flexible, in a complex environment it can be difficult to adapt, maintain, and test automation scripts, particularly if cross-system or cross-application dependencies exist. Therefore, usually one cluster is limited to one application scenario and cross-application dependencies are neglected.
· Goal-Driven Software
In some automation products the emphasis has switched from purely script-driven automation to goal-driven automation. Automation programmers now define the default behavior of the systems and application components in terms of dependencies, triggering conditions, and scheduled requests.
The goal-driven design provides both speed and a high degree of automation while avoiding the complexity of scripted automation tools, hence reducing automation errors.
The automation manager works to keep systems in line with these goals and prioritizes operator requests by using its awareness of status, dependencies, and location of all resources to decide what resources need to be made available or unavailable, when, and where. The number of checks and decisions it has to make can be very high. A human simply cannot do this as quickly and reliably as the automation manager.
Goal-driven automation greatly simplifies operations. Operators just request what they want, and automation takes care of any dependencies and resolution of affected or even conflicting goals. Landscape-wide automation can also remove the need for specifying extra configurations for backup purposes. Instead, cross-system dependencies and server and system goals can be used to decide which backup system is to be chosen.
Given that the SAP system is generally critical to the operation of the business and that human errors can occur, the use of an automation tool that responds in a consistent way to a particular event can help you achieve continuous operation.
Automation software, as discussed above, checks the availability of services. This is achieved by monitoring the availability of the system, the network and file system resources, and the processes. In other words, automation software gives you an outside view of the SAP system.
In contrast, a health check can help you extend this outside view by verifying that a particular SAP component is responding. The following tools are available and you use them remotely because they are TCP/IP based:
You can use this tool to monitor the message server. In response a list of active application servers is returned.
· rfcping or sapinfo
Both tool are similar and you can use them to monitor an application server instance.
You can use this tool to monitor the standalone enqueue server and the enqueue replication server.
Many companies recognize the need for maintaining a backup environment in a geographically distant location. The approach is to mirror the primary application environment and propagate changes in the data and configuration to the second location.
In the event of disaster, the automation recovery procedures needs to at least:
· Break the data propagation
· Recover a consistent state of data, including the backout of in-flight transactions from a mirrored database
· Start the backup database
· Reconfigure the network
· Restart the applications on the secondary side, using the backup database
Automation software again makes sure that both data and applications are recovered in a timely and seamless fashion.