Skip to main content
NetApp Solutions SAP

Example implementation


Due to the large number of options available for system and storage setups, the example implementation should be used as a template your individual system setup and configuration requirements.

Note The example scripts are provided as is and are not supported by NetApp. You can request the current version of the scripts via email to

Validated configurations and limitations

The following principles were applied to the example implementation and might need to be adapted to meet customer needs:

  • Managed SAP systems used NFS to access NetApp storage volumes and were set up based on the adaptive design principle.

  • You can use all ONTAP releases supported by NetApp Ansible modules (ZAPI and REST API).

  • Credentials for a single NetApp cluster and SVM were hard coded as variables in the provider script.

  • Storage cloning was performed on the same storage system that was used by the source SAP system.

  • Storage volumes for the target SAP system had the same names as the source with an appendix.

  • No cloning at secondary storage (SV/SM) was implemented.

  • FlexClone split was not implemented.

  • Instance numbers were identical for the source and target SAP systems.

Lab setup

The following figure shows the lab setup we used. The source SAP system HN9 used for the system clone operation consisted of the database H09, the SAP CS, and the SAP AS services running on the same host (sap-lnx32) with installed adaptive design enabled. An Ansible control node was prepared according to the Ansible Playbooks for NetApp ONTAP documentation.

The SAP host agent was installed on this host as well. The NetApp provider script as well as the Ansible playbooks were configured on the Ansible control node as described in the “Appendix: Provider Script Configuration.”

The host sap-lnx49 was used as the target for the SAP LaMa cloning operations, and the isolation-ready feature was configured there.

Different SAP systems (HNA as source and HN2 as target) were used for system copy and refresh operations, because Post Copy Automation (PCA) was enabled there.

This image depicts the various SAP host agents and how they interact with NetApp storage through NFS mounts. The SAP LaMa instance is also represented.

The following software releases were used in the lab setup:

  • SAP LaMa Enterprise Edition 3.00 SP23_2


  • SAP 7.77 Patch 27 (S/4 HANA 1909)

  • SAP Host Agent 7.22 Patch 56

  • SAPACEXT 7.22 Patch 69

  • Linux SLES 15 SP2

  • Ansible 2. 13.7

  • NetApp ONTAP 9.8P8

SAP LaMa configuration

SAP LaMa provider definition

The provider definition is performed within Automation Studio of SAP LaMa as shown in the following screenshot. The example implementation uses a single provider definition that is used for different custom provisioning steps and operation hooks as explained before.

Screenshot of SAP provider definitions in SAP LaMa GUI.

The provider netapp_clone is defined as the script registered at the SAP host agent. The SAP host agent runs on the central host sap-jump, which also acts as the Ansible control node.

Screenshot of individual provider definition named netapp_clone under General tab. Shows Summary section, used-for section, and Options section.

The Used in tab shows which custom operations the provider is used for. The configuration for the custom provisioning NetAppClone and the custom hooks Delete NetAppClone and Delete NetAppClone Refresh are shown in the next chapters.

Screenshot of Used-In section with list of custom operations that use the definition. In this example, we see Delete NetAppClone, Delete NetAppClone Refresh, and NetAppClone.

The parameters ClonePostFix and SnapPostFix are requested during the execution of the provisioning workflow and are used for the Snapshot and FlexClone volume names.

Screenshot of Parameters section with list of two parameters: CLonePostFix and SnapPostFix.

SAP LaMa custom provisioning

In the SAP LaMa custom provisioning configuration, the customer provider described before is used to replace the provisioning workflow steps Clone Volumes and PostCloneVolumes.

Screenshot of Custom Provisioning configuration screen. The processes CloneVolumes and FinalizeCloneVolumes are listed.

SAP LaMa custom hook

If a system is deleted with the system destroy workflow, the hook Delete NetAppClone is used to call the provider definition netapp_clone. The Delete NetApp Clone Refresh hook is used during the system refresh workflow because the instance is preserved during the execution.

Screenshot of Custom Hooks screen containing the custom hooks Delete NetAppClone Refresh and Delete NetAppClone.

It is important to configure Use Mount Data XML for the custom hook, so that SAP LaMa provides the information of the mount point configuration to the provider.

Screenshot of Delete NetAppClone General screen with

To ensure that the custom hook is only used and executed when the system was created with a custom provisioning workflow, the following constraint is added to it.

Screenshot of Delete NetAppClone Constraints page. Contains a single constraint called Custom clone process name (Static).

More information about the use of custom hooks can be found in the SAP LaMa Documentation.

Enable custom provisioning workflow for SAP source system

To enable the custom provisioning workflow for the source system, it must be adapted in the configuration. The Use Custom Provisioning Process checkbox with the corresponding custom provisioning definition must be selected.

Screenshot of the SAP LaMa Configuration > Systems> System Details screen. Use Custom Provisioning Process checkbox is highlighted.