Placeholder image

SAP Testing Automation Framework (STAF)

| Devansh Jain | Dennis Padia | Hemanth Chowdary Damecharla |

Automation

YouTube

Spotify

Apple

Episode #274

Introduction

In episode 274 of our SAP on Azure video podcast we talk about testing your SAP systems using SAP Testing Automation Framework, by provding a systematic, repeatable way to validate your SAP systems infrastructure configuration and HA cluster functionality.

Find all the links mentioned here: https://www.saponazurepodcast.de/episode274

Reach out to us for any feedback / questions:

#Microsoft #SAP #Azure #SAPonAzure

Summary created by AI

  • Overview and Purpose of SAP Testing Automation Framework (SDAF):
  • Goran, Hemanth Chowdary, Dennis, and Devansh discussed the SAP Testing Automation Framework (SDAF), an open-source orchestration tool designed to validate SAP infrastructure deployments on Azure, emphasizing its role in automating validation, reducing manual effort, and ensuring compliance with best practices.
    • Framework Introduction: Hemanth Chowdary explained that SDAF is an open-source orchestration tool for validating SAP infrastructure deployments on Azure, aiming to help customers maintain optimal SAP system performance by uncovering potential issues before they impact production.
    • Automation Benefits: The team highlighted that SDAF automates processes that traditionally required hours or days of manual effort, making validation repeatable and results consistent, which is particularly valuable for go-live preparations, compliance audits, and pre-maintenance testing.
    • Testing Types: SDAF supports two main types of testing: high availability functional testing, which simulates failure scenarios to verify cluster and service responses, and configuration checks, which perform read-only validation of SAP system settings against Azure best practices and SAP notes.
    • Agentless Operation: Devansh and Hemanth Chowdary emphasized that SDAF operates agentlessly, requiring only SSH connectivity from a management server to SAP VMs, with no need to install agents or packages on the SAP servers, addressing common customer concerns about agent installation.
  • Technical Architecture and Execution Process:
  • Devansh and Dennis detailed the technical workflow of SDAF, including management server setup, test initialization, parameter configuration, execution using Ansible and Python, and comprehensive reporting, with a focus on agentless operation and security.
    • Management Server Setup: Devansh described the process of setting up a management server, which can reside in the same or a different virtual network as the SAP environment, and is responsible for initiating and managing test executions.
    • Test Initialization and Parameterization: Users select the type of test (high availability or configuration check), provide SAP system connection details, and specify parameters such as IP addresses and instance numbers, all of which are persisted on the management server for repeatability.
    • Execution Mechanism: SDAF uses Ansible playbooks and Python modules to establish SSH connections to SAP VMs, execute tests, gather logs, and consolidate results, with all operations initiated from the management server and no changes made to the SAP systems.
    • Security and Permissions: Dennis noted that the management server requires appropriate Azure permissions, such as system or user-managed identity with read access to relevant resources, to collect infrastructure data; missing permissions may cause some checks to fail.
  • High Availability Functional Testing Features:
  • Devansh and Dennis explained the high availability functional testing capabilities of SDAF, including simulation of real-world failure scenarios, offline validation, and support for large databases, with recommendations for safe usage in production environments.
    • Failure Scenario Simulation: SDAF can simulate various failure scenarios such as network disconnections, storage outages, VM crashes, and service failures, verifying that clusters and services recover as expected and generating detailed logs for each test.
    • Offline Validation: A recent feature allows users to perform offline validation of high availability cluster configurations by exporting cluster configuration files (e.g., pacemaker XML) and running checks without connecting to SAP VMs, which is useful in restricted environments.
    • Support for Large Databases: Dennis highlighted that SDAF now supports high availability testing on existing databases of significant size, advising customers to first test in quality environments and to allocate sufficient maintenance window time (up to 90 minutes) for end-to-end testing.
    • Usage Recommendations: The team recommended running high availability functional tests during maintenance windows and ensuring that all test scenarios are validated in non-production systems before applying them to production.
  • Configuration Checks and Reporting:
  • Devansh and Dennis described the configuration checks feature, which validates SAP system configurations across infrastructure, OS, and application layers, generates detailed HTML reports, and provides actionable insights with direct links to SAP and Microsoft documentation.
    • Comprehensive Validation: Configuration checks validate infrastructure, operating system, high availability, and database configurations, collecting data from both Azure and SAP VMs via SSH, and analyzing parameters such as disk performance, kernel settings, and service status.
    • Nonintrusive Operation: The checks are read-only and do not modify the SAP systems, ensuring that the validation process is safe and nonintrusive for both HA and non-HA environments.
    • Reporting and Troubleshooting: SDAF generates HTML reports summarizing the results of hundreds of checks across multiple VMs, highlighting failures, providing detailed error information, and including direct links to relevant SAP notes and Microsoft documentation for remediation.
    • Scalability and Extensibility: The tool supports validation across large SAP landscapes with many systems and VMs, and the number of checks is expected to increase over time as best practices evolve and new features are added.
  • Internal Use, Customer Adoption, and Community Collaboration:
  • Dennis, Devansh, and Goran discussed SDAF’s origins as an internal Microsoft tool, its adoption by customers for regular validation, and its open-source nature, inviting community contributions and feedback via GitHub and official documentation.
    • Internal Testing and Updates: Dennis explained that SDAF was initially developed for internal quality testing of new OS releases and SAP workloads, with lessons learned and improvements incorporated into the public tool.
    • Customer Usage Patterns: Devansh noted that customers commonly use SDAF before quarterly or half-yearly releases to validate their SAP environments, leveraging the tool’s automation to ensure compliance with evolving best practices.
    • Open Source Collaboration: Dennis encouraged the community to contribute by raising issues or feature requests on GitHub, emphasizing that SDAF is open source and collaborative, with documentation and support available through official Microsoft channels.

Links

Video index

Based on and using Hugo Cookbook Theme, Font Awesome Icons and Bulma CSS. | Thanks to Recipes4AJ to get me started. | Contact me via