Load Balancing Auto-Configuration for SAP using Workflow Studio and NetScaler

At the tail end of our certification process at SAP, Citrix engaged in a unique opportunity to make use of the SAP APIs, using Workflow Studio to auto-configure the Citrix NetScaler for Load Balancing. The way it works is, Workflow Studio polls the SAP API, reads the response, and then based on the results in the response, configures the NetScaler Load Balancing groups that map directly to the SAP servers running in the server farm.

SAP has a community group dedicated to the development of their APIs, please reference the latest blog post Catching Up with Deployment and Operations Automation, describes the SAP APIs.

The SAP Community Definition Group (CDG) - titled "PCDG 97 NetWeaver Infrastructure APIs for Network Solutions" - is focused on automation of network-application integrated configuration and operation. As the group title implies, the SAP NetWeaver technology platform includes APIs, which are used by the NetScaler ADCs (load balancers) to auto-configure themselves as proxies for multi-instance SAP application systems. Using Citrix Workflow Studio, the SAP APIs are polled on a regular basis so that the NetScaler ADCs can react to SAP application instance changes during production runtime.

If another application instance is brought up, let's say for providing more computing capacity for an increasing end-user load, or if an instance is brought down temporarily for maintenance, Workflow Studio communicates with the NetScaler ADC to adjust load balancing automatically without any manual administrator intervention. There is no more wait, or lengthy change management required to provision applications.

Workflow Studio, NetScaler and SAP API Use Cases:

Use Case 1: (auto-configure new SAP services).

Workflow Studio sends a URL request to the SAP Message Server, and receives a response. Workflow Studio parse's the response, looking for specific SAP generated patterns. WFS then uses this information to configure a Load Balancing Virtual Server inside of the Citrix NetScaler.

Use Case 2: (dynamic configuration).

Workflow Studio repeatedly queries the SAP API. WFS studio can determine hostnames, ip addresses, port numbers, and whether an SAP server is coming online or going down. When a SAP server comes online/goes down - WFS detects this change, and then takes action on the Citrix NetScaler, to add/remove the SAP service from the Load Balancing group - automatically.

Use Case 3: (graceful shutdown).

Workflow Studio queries the SAP API, determines a SAP server is going down, and based on the response, waits until all existing sessions have been retired, before removing the server from the Load Balancing group . During the shutdown period, no new sessions are added to that SAP server, providing a graceful shutdown of the SAP service. This way, there are no TCP resets sent to existing sessions. New logins are routed to a different server.

Read the SAP article here.

Tap into the power of AppExpert!

To start off my blog here, I've put together a small example of how to use javascript to interact with an unmodified XenServer using the XMLRPC API. Mostly of the work is done by the awesome jquery library and a slightly modified jquery.rpc plugin. To illustrate the basics this demo will simply list the names of the VMs and templates that XenServer knows about - in subsequent posts I'll put together some more interesting examples. A zip file containing the code can be found here.

The demo consists of an index html page which more-or-less just includes the two jquery files and the demo.js file. The simplest way of trying it out is to is to put the files onto the XenServer to be served by the integrated web server. This is done by creating the webserver root directory '/opt/xensource/www' and copying the files in.  Alternatively, and more usefully, the files can be loaded locally from a file:// URI. However, this is more tricky because there may well be cross-site scripting protection built into the browser - certainly Firefox has this feature and there are commented-out lines in the demo files explaining how to deal with this.

I'll just describe here the demo.js file. To talk to the XenServer, we must first create the jquery rpc object. In versions of XenServer prior to 5.0 the system.listMethods method was not implemented, so we have to explicitly list the methods that we'll be using when creating the rpc object.

  rpc = new $.rpc(
    actual_uri,
    "xml",
    nextfn,
    null,
    ["session.login_with_password","VM.get_all_records"]
  );

In this case, we're only going to use two API calls. Of the other parameters, 'actual_uri' is the URI of the XenServer to connect to, and could be e.g. "http://<ip>/" if the files are not being hosted by XenServer, or simply "/" if they are. 'nextfn' is the function to call on successful creation of the rpc object. Once the object is initialised, we can call API functions:

var session_result = rpc.session.login_with_password(username,password);

    if(session_result.Status=="Failure") {
      raise("Failed to log in");
    }
    mysession = session_result.result.Value;

When we first started investigating the javascript route to the API, we found that the parsing of the XMLRPC results was often very slow indeed. We tried a couple of methods for dealing with this - one interesting idea was to use an XSLT transform to turn the xmlrpc response into json, which worked well and significantly speeded up the processing time of calls that produced large results (e.g. VM.get_all_records). However, it was decided as a tradeoff between complexity and effectiveness that inside xapi itself we would put a little converter that translated the XMLRPC 'result' field into json, leaving it embedded in a small amount of xmlrpc to avoid adding an entirely new layer of logic into xapi. This had a huge impact on the speed of processing for very little code change. In order to access this semi-json API it's a simple case of appending '/json' to the URI used for the standard XMLRPC calls. I've added a 'use_json' field to the demo javascript as an example of how it's used.

Next time I'll explain how the event mechanism works, and how it can be used to keep an up-to-date cache of the entire XenServer database.

The purpose of this document is to provide best practices from an application developer's perspective on the common nuances encountered with application development for troubleshooting application issues in a seamless Citrix environment.