Skip to Content

Disaster Recovery in SUP server with an IMO based client

Disaster recovery procedure for SUP-ODP

Applies to

SUP 2.1.x (not sure)

SUP 2.2.x ( verified post 2.2 sp04)

SUP 2.3.x (verified)

Summary

Sometimes while using the SUP server, in case it suddenly stops working for some reason there should be a way out to recover from that state. Hence, as a  pre-requisite I came up with a couple of situations where I simulated a failure and tried to recover the server from that state.

In this document, we shall discuss about the recovery methods that the SDK/ client can incorporate to recover from the “disaster”.

Author

SHARVARI     

Company:    SAP LABS INDIA PVT LTD

Created on:  9 November 2013

Author Bio

Sharvari | sharvari@sap.com

Quality Associate ,

Engineering Services, SUP-ODP

SAP Labs India PVT Ltd

Disaster Recovery in SUP server with an IMO based client

This document deals with a hypothetical situation where something goes wrong with the server unexpectedly. Hence, this is just like a pre-requisite that can be followed rather than feeling sorry later on.

I don’t say that this is a mandatory procedure. However, I have got the steps documented in the release bulletin as well.

BACK-UP

 

As soon as the server is installed, please follow the steps given below and then go ahead with any configuration that would be made in the SCC:

Step 1

Install the SUP server.


Step 2

Log into SUP server with the credentials provided during the installation process.

Step 3

Create an application ID, security configuration, application template (combination of the application Id and security configuration).

Step 4

Go to start option and type services.msc. This will take you to a list of services in the machine. Go to Sybase related services.

They will be:

  1. SAP control center
  2. SAP Mobile Platform
  3. SAP Mobile Server

All of these services should be stopped before keeping a copy of the data folder.

In order to stop the services, you can follow two ways:

  1. Stopping the services directly -> Right click on the service that you want to stop and select stop.
  2. If a shortcut icon is already there for start/stop of the server, you can right click on the icon( stop sybaseUnwired Platform services) and select run as administrator.

This will stop the services. Now we are ready to take a copy of the data folder as in the next step.

Step 5

At this stage go to the folder location where the installer files are located. ( ex: C:\SAP\UnwiredPlatform\Servers\UnwiredServer\Data)

In case of 2.x servers, the location would be: C:\Sybase\UnwiredPlatform\Servers\UnwiredServer\Data.

Step 6

Once the data folder is copied , we will have to restart the services to continue with any of the operation using SUP server.

To start the SUP server services, Go to the shortcut icon-> Start Unwired Platform Services-> Right click -> Run as Administrator. This will start all the services.


Step 7

Go ahead with registration of the user followed by request response.

RECOVER

Now, let’s discuss on how we could recover from the disaster state and use of the copied “data” folder:

  1. In case something goes wrong with the SUP server, the only thing we have to do is to stop all the services as done before and replace the existing data folder. With the data folder which we had copied before doing any onboarding or request response.

  2. In case the user was registered and after this the data folder is replaced with the copied data folder, user details will not show up in the scc.
    This is when the problem sets in. Now, from the client, calling the login/ register User API will tell that the user is already registered but request response fails as the user is not there in the scc. The reason being the user details would still be available on the device.
    On the other hand, since the user is not in SCC, request response would fail with a message that the user is no longer available or has expired.

Solution to recover from this state:

    1. Call the deleteUser API that would deregister the user from the device/ client.
    2. Call the registerUser Api once again. This would register the user in the scc after which all other operation should continue to work normally.
    3. Request response with the newly registered user would go on as desired.

Note: I would prefer to keep the copy of the “data” folder at different stages:

    • As soon as the server is installed
    • After the application id and the templates are created.
    • After the users/ application connections are registered with the SUP server.

Note that you will have to stop the services each time you copy the data folder. This might be tedious but helpful at some point in time

This will give you a flexibility to decide which state would be best suited when you something goes wrong.

Tags:
Former Member