The SAP CRM system landscape is a complex infrastructure with many components that are integrated with the SAP CRM server. These components include the SAP ERP back-end system, the Communication Station, Software Agent Framework (SAF), the Mobile Application Studio (MAS), the Mobile Application Repository (MAR), and the CRM Mobile Client. Some of these components have a different database than the SAP CRM server. As a result, managing backup, restore, and recovery operations can be challenging, especially as they relate to data volume, sources, repositories, integrity, and consistency. If appropriate strategies are not in place, it can lead to the loss of data and system downtime. Therefore, it is expedient to build and implement a strategy that is well-poised to handle these challenging areas.

Data Safeguarding Strategies

The backup concept for the SAP CRM server follows the standard backup methodology recommended by SAP for a standard SAP ERP system. The procedure involves the backup of databases, file systems, database files, log files, and SAP files on different media (e.g., tapes, files, and pipes) using various backup tools.

The backup cycle is the time period in which you keep backups on tapes. The backup cycle defines the retention period for these tapes, which means that a tape cannot be reused if its retention period has not elapsed. SAP recommends a backup cycle of four weeks. Depending on your business requirements, it is important that you perform these best practices for backups:

• A complete online backup daily
  
  
• A complete offline backup at least once every four weeks
  
  
• A backup of offline redo log files daily and after every online and offline backup
  
  
• A logical check and verification of the database before or after a backup operation
  
  
• A backup verification once a week

You can perform a full or incremental backup. A full backup stores all information in the database. If you have performed a full backup of the SAP CRM database, an incremental backup allows you to perform a backup of the changes to the database or file system since the last full backup. This reduces the amount of data that you need to back up. Take care when using incremental backup, because an incremental backup might not be usable if the corresponding full backup is unavailable or unable to be used.

Depending on the database system on which your SAP CRM server and other components run, you can perform backup, restore, and recovery operations using different programs. For example, you can use BR*Tools and Oracle Recovery Manager (RMAN) to perform these operations with the commonly used Oracle database. BR*Tools is a program package that contains BRBACKUP (Figure 1), BRARCHIVE (Figure 2), BRRESTORE, and BRRECOVER (Figure 3). RMAN is the default Oracle backup and restore program, and you can integrate it into BRBACKUP and BRARCHIVE to provide more flexibility to your backup strategies. You can also configure BR*Tools to use an external backup utility through BACKINT.

Figure 1

BRBACKUP main options for backup and database copy

Figure 2

BRARCHIVE main options for archivelog backup

Figure 3

BRRECOVER options for restore and recovery

Using the central Database Administration (DBA) Planning Calendar available in transaction DB13C, you can schedule any combination of backups — including full backups, incremental backups, and log file backups (Figure 4). Note that the “SCD” in the term Oracle Database SCD in Figure 4 is the particular database name I used when I was performing the system installation. This could be different in your system (e.g., BCM, DCP, or KEN).

Figure 4

DBA Planning Calendar with backup options (see inset)

Use transaction DB14 to access the DBA operations monitor (Figure 5). Here you can monitor database operations such as backup jobs.

Figure 5

DBA operations monitor

In the event of a crash of the SAP CRM server or any dependent component, your strategy for recovery must include a comprehensive problem-handling concept. Before you restore any file, it is a best practice to:

• Identify the cause of the crash (e.g., disk errors, non-disk hardware error, or software malfunctioning)
  
  
• Check if there is enough space to save and restore the backed-up files
  
  
• Identify the file system and mount point
  
  
• Confirm the availability of the necessary backups and log files

Imagine you have a hardware-related problem such as a hard disk crash. You might need to replace the faulty hard disk and then restore the last backup. In the event of a crash without a disk error, you can restart the SAP CRM server and SAP ERP server and restore services. It is important that you check the status of the queues in all dependent systems via transactions SMQ1 (outbound queue) and SMQ2 (inbound queue). Some queues may have incorrect statuses (i.e., SYSFAIL) because they could not be completely processed as a result of the server crash. Execute programs RSQOWKEX and RSQIWKEX for all queues to correct any SYSFAIL statuses. In addition, use transaction SM37 to check whether the crash of the SAP CRM server affected CRM Middleware background jobs such as the reorganization job. If the background job was affected, restart the job.

A recovery can be complete or incomplete depending on the adopted strategy, business environment, and backup availability. A complete database recovery is performed if the crash makes the database inconsistent or unavailable. It restores the database to its committed status before the crash occurred. This approach copies only the minimum amount of data from the backup medium to the disk. A point-in-time recovery is often performed to reset the database to its status at a particular time (e.g., before changes to configuration settings) and then recover the database to a later point in time. An incomplete recovery defines the end point of recovery, which is typically anywhere between the end of the copied backup and the last entry in the current log file. You always lose some data when performing an incomplete recovery.

You should test and validate your recovery procedure before and after go-live. Test it regularly to ensure there are no unpleasant surprises if you perform a recovery operation in the event of a crash. You can test your recovery procedure by simulating a crash of any component by shutting down the system while data is being exchanged between the SAP CRM server and the SAP ERP server. You would then perform a recovery afterwards. However, it is a best practice to use a consistency check tool such as the Data Integrity Manager to ascertain the consistency level of SAP CRM and SAP ERP before simulating the crash.

For certain parts of the SAP CRM system landscape, such as Groupware integration and ABAP Software Agent Framework (SAF), the backup and restore of the SAP CRM server database alone suffices. For example, Groupware integration allows for the exchange, synchronization, and replication of data such as contacts and activities between the SAP CRM server and a Groupware system (e.g., Microsoft Outlook or IBM LotusNotes). This lets Groupware users access contacts and activities created in the SAP CRM server for transaction processing. If the Groupware application crashes, you can restore it after restoring the SAP CRM database. For the SAP ERP back-end system, the backup concept is not very different from the SAP CRM server’s concept.

However, for other components of the SAP CRM landscape — especially mobile-centric components such as MAS, MAR, CRM Mobile Client, and Communication Station — a few important exceptions exist. I’ll discuss these next.

The Mobile Application Studio

The MAS is a visual development tool for the development and application requirements of SAP mobile client applications. The MAS is object-oriented and allows for the customization of mobile client applications to suit the needs of a particular business environment. You can also use it for the development of new applications. The MAS is installed automatically and for free on all Mobile Development Workstations where mobile client applications are developed and tested. All development data is stored in the MAR, which I discuss in the next section. Although no data is saved in the MAS, you should perform a regular backup of the file system. It is a best practice to carry out the backup of the MAS after installations, upgrades, or system modifications. In the event of a crash, you can reinstall the system if you do not want to restore the system using the file system backup.

The Mobile Application Repository

The MAR is installed automatically and for no extra charge on the Mobile Repository Server for each environment in the SAP CRM system landscape. In a three-system landscape, these environments are development, quality assurance, and production. You use the standard Change and Transport System (CTS) to manage the software logistics processes of released development objects. Change lists are transported from the development system to the quality assurance system before finally being transported to the production environment. It is important to note that the released development objects from the MAS should be transported independently and separately from standard SAP objects. A regular file system backup, database backup, and continuous logs backup of the MAR are essential for ensuring complete recovery in the event of a crash of the MAR. This applies to the development and production systems. To carry out a restore operation for the MAR when a failure occurs, you need to:

• Restore the backup of the file system or perform a reinstallation of the system
  
  
• Restore the repository database and apply the logs. Alternatively, if the expertise exists in your organization, you can re-import the released development objects for the production system.

CRM Mobile Client

CRM Mobile Clients are laptops that run field sales and field service application clients and are usually disconnected from the SAP CRM server when there is no business need to exchange data with that server. The field sales and service clients consist of all applications needed for offline data entry and transaction processing. They also facilitate data exchanges between the CRM Mobile Client and the SAP CRM server. In a normal environment, you do not need to back up the CRM Mobile Client because it is typically installed on a laptop with all data sent to the SAP CRM server via the program ConnTrans. To synchronize data between the SAP CRM sever and the CRM Mobile Client, you can either call the ConnTrans program or execute ConnTrans from the command line. (A network connection via LAN or dial-up is needed.) Regular data exchange between the mobile client on the laptop and the SAP CRM server reduces the need for a CRM Mobile Client backup because the SAP CRM server performs the backup of the database.

You should establish the connection from the CRM Mobile Client to the SAP CRM server at least once per day to facilitate the seamless upload of transaction data. This is important because it eliminates problems associated with the incomplete recovery of the SAP CRM server in the event of a crash that requires backup, restoration, and recovery. Incomplete recovery of the SAP CRM server database can cause data inconsistencies and, subsequently, the loss of original mobile client data when a full extract is sent to the client. You can also create the image of the CRM Mobile Client with system imaging tools. In the event of a crash of the CRM Mobile Client, you can restore the image you created or perform a new installation. You can then initiate a download process for the mobile client data to the CRM Mobile Client after you complete data extraction and fill the outbound queue on the SAP CRM server. In addition, it’s important to know that you can use the Mobile Client Recovery Manager to quickly and easily restore mobile clients.

The Communication Station

The Communication Station is an optional machine in the SAP CRM system landscape that the CRM mobile client uses when it connects to the SAP CRM server for a data exchange. The Communication Station supports multiple connections to the SAP CRM server. It also provides authentication services for mobile clients before they are connected to the network. In the event of a crash, there is no serious data loss within the Communication Station. A simple reinstallation of the software will do. You can use the Mobile Rollout Manager to ensure the easy rollout of new laptops with all the necessary data for transaction processing at a customer site.

However, you need to perform the backup of the Communication Station log file TransferService.log on an ongoing basis. This is because you can use it for client connections, audits, troubleshooting, and analysis. Some examples of situations in which this file can help are:

• Incorrect configuration of destinations for the Communication Station and the SAP CRM server
  
  
• Link failure between the Communication Station and SAP CRM server during data transfer
  
  
• Link failure between the Communication Station and mobile client

Other information registered in the TransferService.log file includes:

• The number of messages sent to the SAP CRM server from the outbound queue of the mobile client
  
  
• The number of messages received from the SAP CRM server that remain in the inbound queue of the mobile client
  
  
• Time (estimate and actual) to transfer these messages

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.