Tip:
Highlight text to annotate it
X
This video will take you through creating a stub for Worklight Server, using Ration
Integration Tester, or RIT. In this demo, the Worklight Server is connected to other
back-end systems using Worklight adapters. So when we stub out the Worklight Server,
we are replacing the entire back-end system with a stub. It is also possible to stub out
only a part of the back-end.
In order to create stub for Worklight Server, we need to route the traffic between the mobile
app and Worklight Server via a HTTP proxy. The HTTP proxy intercepts HTTP traffic, and
the captured messages are used to create a stub.
To setup proxy in the Android emulator, go to
Settings > Wireless & networks > More > Mobile networks > Access Point Names
Next, we will setup a binding to the Worklight server.
Launch RIT, create a new project. Create a Service Component, which is a model of the
real back-end, in this case, that is the Worklight Server.
Let's create a HTTP connection as the app is talking to Worklight server using HTTP.
Let's create an environment named TEST and set binding to it.
Select External Proxy Server.
Click Test Transport to verify the connection to the Worklight server. Click OK to save.
Now we are ready to start recording HTTP traffic. Right click Worklight server component > Record.
This switches to the Recording Studio perspective. Start recording.
Launch the app. As we perform operations in the app, it makes REST calls to the Worklight
server, which are intercepted and displayed in the Events View in RIT as request-response
pairs.
Log in and 3 pairs of REST messages are captured.
The 401 Unauthorized is Worklight's authentication framework. This is for the client to identify
itself to the server.
During log on, two REST calls are made to the back-end, one for authentication and the
other for retrieving accounts, which are displayed on the main page of the app.
Another REST call is made to get a list of charity organizations.
Another REST call is made to get nearby charities based on current location, which are then
displayed in a Google map.
Let's send a mock location to the emulator using DDMS perspective.
All the required messages are captured, now log out the app.
Next, let's generate a stub using the captured message.
Pause recording.
Highlight all messages corresponding to the operations being stubbed out. Save the stub.
Once we click Define Operation, RIT recognizes the operations being captured, which are the
user, accounts, organizations and charities REST calls.
Finish the wizard and give a name the stub.
Let's edit the stub before running it.
Select user event. The x element is a random value which changes in each invocation by
Worklight design. Let's skip checking equality for x.
Now switch to the Output tab, double click to open the response message body, remove
the /* secure */ comment (at beginning and end of message body), click OK to save. The
secure comment is by Worklight design, for security reasons.
Notice that the JSON message is now recognized.
For the purpose of demo, let's modify the response message. Change the first name of
the user from Julie to James. This will make it easier to identify the response is coming
from the stub.
Repeat the same steps for the other events.
Save the changes.
Let's publish the stub to Rational Test Control Panel, or RTCP.
Start the stub in RTCP. Wait until status becomes Ready.
The Worklight server stub is now published and started on RTVS and is ready to use.
Thanks for watching.