CAMDM

Table of Contents

CAMDM Application Technical Stack: ........................................................................................................... 1

CA MDM Request flow: ............................................................................................................................. 2
Direct:........................................................................................................................................................ 2
Through Relay server: ............................................................................................................................... 2
CA MDM Architecture:.............................................................................................................................. 2
Issues and solutions while working with Xnet protocol Communication: .................................................... 2
Identified the following scenarios for Performance Test. ........................................................................ 3
Challenges faced while running with multiple users ................................................................................ 4
Issues and solutions while working with HTTP protocol Communication: ................................................... 4
Issues and solutions: ................................................................................................................................. 4
Tried multiple ways to achieve this .......................................................................................................... 5

CAMDM Application Technical Stack:

CA Mobile Device Management (MDM) is an enterprise solution for securing and managing the
following features:

The Mobile users

Devices

Applications

Content (data) with your enterprise policies

 CAMDM
CA MDM Request flow:
Direct connection between client and MDM server:
Http protocol:
Request sent from the client will first hit XSRedirector (Here it will change into Server understandable
format), later it will hit XComm and last it will hit database server.

Xnet protocol:
Request sent from the client will directly hit XComm and later database(Here it wont hit XSRedirector)

Connection through Relay server:

Request sent from the client will hit Load balancer Relay server XSRedirector XComm
database server.

CA MDM Architecture:

Client-1

Client-2 Load Relay XSRedir

Rsoe ector
XComm
Database
Balancer Server

Client-3

Client-4
 CAMDM
Rsoe relay server outbound enabler flow:

Issues and solutions while working with Xnet protocol Communication:

As CAMDM application is not a web-application and not browser dependent it is hard to record from the
JMeter which will use browser proxy for capturing the requests.

I have tried to record with the following tools to capture the requests, which didnt work

o Load Runner
o Grinder
o Gatling
o Fiddler
o NeoLoad

Finally, able to record the requests using tools like WIRE-SHARK and MICROSOFT NETWORK MONITOR

Identified the following scenarios for Performance Test.

o Enrollment policy
o Simple message channel
o File transfer channel

Added the requests captured from Wire-Shark into Jmeter tool and able to perform a Baseline Test with
Single User successfully.
 CAMDM
Challenges faced while running with multiple users
Observed the dependency with unique parameters for each virtual user to run the load test.Below are
the parameters for reference.

o "CKY" COOKIE
o "CID" CLIENTID
o "USR" USER PROMPT
o "OSD" CLIENT OS DATA
o "SEV" SESSION VARIABLES
o "STE" OS SUITE
o "EDN" OS EDITION
o "BIT" OS BIT

By changing all the above parameters in the TCP Post request, I was able to add new machines to the
server.

There was a change in the requirement to execute the tests by navigating through Relay Server using
HTTP Protocol instead of sending requests to MDM server directly using TCP Protocol.

Issues and solutions while working with HTTP protocol Communication:

Also, used WIRE-SHARK for HTTP Protocol to capture the communication between the client and the
server. Here we found three requests in the below order

o Get request
o Post request
o Get request

For first GET request only header is going and response (means response code) is coming from the
server

For the POST request, along with header, data packets are also going like continuation requests.

For the second GET request only header is going to the server but the response for all the POST
continuation requests are coming as response in the GET continuation requests.

Issues and solutions:

1. Issue: Content-length: Server is expecting content-length "999999999"in the header.

Solution: To resolve this issue, we used HTTP-Raw Request sampler in the Apache Jmeter.

2. Issue: Content-type, Content-size: Replicated content type and content size same as client which
was validated with wireshark.
Solution: To resolve this issue, exported the data into .bin file format from the wire shark and given
as .bin file in the http raw request.
3. Issue: Source port: Server is expecting all the post requests and get requests must use same source
port for all its communication with the server.
 CAMDM
Solution: To resolve this issue, used only one http raw request for sending header data and data
packets.
4. Issue: Asynchronous calls: Server is expecting all Http get, Http post and Http get must hit the
server at the same time.
Solution: To resolve this issue, Used "Synchronous timer" so that all my requests will hit the server
at a time.

By resolving all the above issues I am able to send requests successfully from the Jmeter and I have
validated in admin portal for un-approved user scenario.

But for execution of normal channels we need to send multiple files in HTTP POST request along with
the header. Jmeter have least feasibility to replicate it.

Tried multiple ways to achieve this

1: Sent header in HTTP Raw request and data packets in another sampler that is without header. In this
case data packets are converting into the TCP protocols, which server is not accepting

2: sent only header in HTTP Raw request and data packets in another sampler with header. In this case
data packets are not going as continuation requests which server is not accepting

3: Later, used normal HTTP Sampler where we found content-type, content-size and content length are
changing by which server is not accepting.

For successful HTTP POST request these are the things need to be done
1: Content-Length must be 999999999

2: Content type and content size must not change

3: Header and all the data packets should send in one post request to replicate continuation requests.
(All the requests should come from the same source port)

4: All the requests should hit the server at a time.

As Jmeter tool is open source tool it wont have feasibility to replicate above requirement, I tried
multiple ways to send all the data packets in one HTTP request but due to tool infeasibility I was not able
to achieve this.

Later I tried JSR-223 sampler in which I can write java code for sending all the requests and I am able to
replicate all the requirements of the server.

Tried with following different samplers

Http sampler- I didnt achieve the requirement due to content length issue so I didnt take the following
samplers into consideration.

Web socket sampler- I didnt achieve the requirement due to protocol issue so I didnt take the
following samplers into consideration.

OS process sampler- I didnt achieve the requirement because it dont have chance to parameterize
 CAMDM
Http raw request sampler- I didnt achieve the requirement because it dont have option to send
multiple packets in order to achieve continuation requests.