A classic SAP landscape has three tiers. A development system is designated for custom-coded SAP elements and customized SAP applications. The quality assurance system is used to verify all changes coming from the development system before it is shipped to the productive system and may contain clients for Integration Testing, User Acceptance Testing and Training. The productive system itself will provide core business processes and hold all live data of the company.
How does this apply to SAP Landscape Management?
Compared to other SAP solutions, LaMa doesn’t have a high demand on resources nor will LaMa hold any company business data, because it is not necessary as an orchestration and automation tool. But still there is a need to have more than one LaMa installed.
The first approach will be the single system installation (1-Tier). While having only one SAP Landscape Management installed, the maintenance of that single system is easy and fast. There is only one NetWeaver JAVA system to keep up to date. All automation is used during normal office hours and planned, or unplanned downtimes of LaMa has no effect on business processes. Customization and testing need to take place in the same system, and it must be acknowledged that side effects may occur.
The second approach is a 2-Tier setup. The 2-Tier setup comes in two versions, one to separate customizing and testing from the productively used LaMa, and secondly in a variant of using inbuilt synchronization functionality to make LaMa highly available.
The 2.1 approach is having a second installment of LaMa, which is purely to create customizing and is used for testing. While creating custom operations, hooks or custom processes, the configuration has to be applied to LaMa and as you’ll see later in this course it can lead to problems when not setting constraints. If you apply customizing to SAP Landscape Management, it will automatically be available to every other system configured in LaMa. Constraints provide a possibility to secure this customizing to be used only for a set of certain systems.
However, constraints must be set by the developer and this is when human error can occur. In a separated LaMa, the need to set constraints is simply not given or in other words has no impact on productive LaMa automation.
_Image.png)
Approach 2.2 is intended to provide a high availability or failover option to LaMa. Of course, as SAP Landscape Management is running on SAP NetWeaver JAVA, high availability can be covered by setting up a third party cluster solution or by using database functionality to make the system highly available. These options will require a more complex setup and third party licenses. SAP Landscape Management has an inbuilt synchronization functionality to replicate the configuration to a second installation of LaMa. The synchronization setup will take place in the secondary LaMa instance, not in the productive instance.
The settings about synchronization options can be found in Setup → Settings → Synchronization/Standby. SAP Landscape Management offers several timing options, from daily, weekly, to expert.
In case daily synchronization is too frequent and weekly is too infrequent, the expert will help to set it up the way it fits best. The expert setting uses an input array in the following form:
Year : Month : Day of Month : Day of Week : Hours : Minutes
The format varies among the input parameters. The first parameter, Year, is provided in the format of YYYY. The Month needs to be provided with a value of 0 to 11, while 0 represents January. Days of Month (DoM) can have the value 1 to 31, depending on the month. Days of Week (DoW) will need an input of 1 to 7, while 1 represents Sunday. Hours can be specified with values from 0 to 23. In combination with the input parameter Minutes, value 0 to 59, you are able to set the exact time. Schedules for multiple days of the month or week can be addressed by using a separator, (comma), for example, 2019:10:*:2,4,6:19:0.
SAP Landscape Management offers three different ways to sync. The first and easiest one to use is the direct way. In this method, the secondary LaMa will connect to the primary LaMa to export the data. You have to specify the URL inside the settings of your secondary LaMa.
The second option is called Destination. It’s similar to the direct method but you don’t have to configure the connection details in here. For this method, you have to create a HTTP Destination inside of the NetWeaver Administrator (NWA) of your JAVA Stack where LaMa is running. The destination must be named LaMa_Synchronization and should have the necessary information.
Last but not least, the third option is via Upload. This option can be used if both LaMa, primary and secondary, can’t reach each other directly. The XML export can be exported and placed to the location specified here. The secondary system will retrieve the file from the location.
For all options you need to set up a password to decrypt the data coming from the production LaMa. The password used to create the XML export must match the password provided here. In case of direct syncs, this password is not transferred. Instead it must be configured as well inside the productive LaMa to be used as a default encryption password.
Find the configuration here: Setup → Settings → Engine
Another option is the Standby Mode. Activating the Standby Mode means the development LaMa will receive updates, configuration wise, but is not operational. In case of a planned or unplanned outage of your productive LaMa, you can switch off the Standby Mode option to enable the development LaMa to become operational again.
While setting up the Standby Mode, certain jobs LaMa usually does are disabled. This is mandatory if customers want to use the Standby Mode. If you want to enable one of these services, you will not be able to be in Standby Mode.
But still, to enable one of these jobs will enable your secondary LaMa to operate as you wish and will mainly answer the question of:
Can I use my secondary LaMa as development and failover instance at once?
Yes, your development LaMa can be used as development and failover instance at the same time.
But there are some things to keep in mind:
Monitoring data – if you activate the monitoring job both LaMa will use the host agent to pull monitoring data. This means a higher load in network traffic, especially in bigger landscapes and can lead to timeouts.
The same applies for the Landscape Scanner. The Landscape Scanner can be used to discover your SAP Landscape and bring in new SAP systems to SAP Landscape Management.
If you’re using our Scheduler, make sure to deactivate the Task Planner job inside the secondary instance. This will disable the possibility to test anything in regards to scheduling.
The most dangerous part is to keep track of who is using which LaMa. Inside SAP Landscape Management, the engine makes sure that duplicate operations can’t be triggered on the same instance, either host or virtual host. Between two LaMa systems this is not handled. Only when Standby Mode is activated and all Jobs are disabled, then the secondary is not operational and explicitly needs to be enabled, if needed.
Release Updates for SAP Landscape Management can be tested in your second instance of LaMa. In rare cases where you have just updated the development instance as an unplanned event, you will need to switch from the prod-instance to the dev-instance.
