Worklight Lessons Learned

Dónal Spring

Agenda

What we did?

- Worklight Apps

- Normal development Vs Continuous Integration

- Building Worklight & Tools used

- Testing

What we learned?

- Adapter Lessons

- How to really debug apps and adapters

- CI & Build Lessons Learned

- Project Pain Points

Android & iOS App ::

eCommerce App
Mixed Native and Hybrid & Web flow
Security integrated through Worklight
Maintained basket across channels

App Features ::

Store Locater
Product reviews
Search / Category lists
360 degree product view
Marketing data and eSpots
Click & Collect

Brief Background

The

App

The Parts

Complex integration with many suppliers

The Suppliers

Project Innovations

Information Radiators
Test Driven Development
Automation
AppCenter for testing distribution
Cloud tooling
- JIRA, Google Docs, Skype, Google Hangouts etc

'Normal' Developement

IDE --> Native tooling --> Deployment

Current issues facing delivery teams

The "it works on my system" attitude

Manual testing / development

Scalable?

CONTINUOUS INTEGRATION

What is it?

How do i do it?

Automation

Build -> Test -> Deploy in a day

Why do it?

Client transparency
Time to market
Encourages developers (make fixes from the pub)
Mitigates integration issues

THE TOOLS

Liberty & Jenkins

code - commit - test <repeat>

Why Jenkins? What about Urban Code / Cloudbees?

--> Plugins

TOOLS

2. Automated ways of building components

.wlapp

.war

.adapter

TOOLS

3. Powerful SCM e.g. GitHub

Pull Requests

Web Hooks

Git Blame

Powerful SCM can boost development time and simplify integration

TOOLS

4. Ant Tasks & Scripts

The "Glue" to hold the process together

Source Code Checkout
Build Worklight artefacts
Deploy .wlapp & .adapters
Build native applications (.ipa, etc)
Execute tests
Deploy Apps to app center

IDEAL STEPS TO PRODUCTION

Pipelines & AppCenter

TESTING

Server Side components (Adapters)

Well defined inputs / outputs

Feedback on code quality & data manipulation

Unit / Integration / Performance

What about Rational Test Bench?

Open source UI testing?

ADAPTER URL

check in POSTman (localhost Vs webserver)

Worklight security and XSS?

invokeWL.js - npm

NOTE : adapters are currently not RESTful

* URIencode for safety *

var baseUrl = "http://" + domain + ":" + port + "/" + contextRoot;
var address = baseUrl + 
    "/invoke?adapter=%ADAPTERNAME%&procedure=%PROCEDURENAME%¶meters=%PARAMETERS%";

A Basic Test

Before & After hooks

Integration Test

Reporting and Automation

spec / html / Xunit / nyan ....

Jenkins processing of test results ( . )

What about stubbing solutions?

Worklight to host JSON

stubby

Lessons Learned

The Worklight Adapter

ADAPTER VERSIONING

What is it?

Why is it important?

How do we implement it?

The options Object { }

Client code ::

Adapter code ::

var options = { version: { major: 1, minor: 0, patch: 0 } }

WL.Client.invokeProcedure({
adapter : "RSSFeed",
procedure : "getData",
parameters : [options, "myTopic"]
});

function getData (options, param) {
      if (options.version === 1){
          // do stuff for version one of the adapter
          input = { 
             method = "get",
             path = param,
             returnedContentType = "json"
          }
          return WL.Server.invokeHttp(input);
      } else if (options.version === 2){
          // adapter v2 mechanics
          // could also be used to call a new adapter:
          invocationData = { adapter : "RSSFeedV2",
                             procedure : getData,
                             parameters : [options, param]}
          return WL.Server.invokeProcedure(invocationData);
      };
};

options object {}

Helps future proof an application
Difficult to retro fit due to app code
Provides platform for extension

Configuring Adapters

Adapter Proxies - in adapterName.xml

<connectivity>
    <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
        <protocol>http</protocol>
	<domain>mydomain.com</domain>
	<port>1080</port>			
	<!--PROXY_SETTINGS-->
	<proxy>
	    <protocol>http</protocol>
	    <domain>myproxydomain</domain>
	    <port>8080</port>
	</proxy>
     </connectionPolicy>
     <loadConstraints maxConcurrentConnectionsPerNode="10" />
</connectivity>

Authenticated proxy's can be used too

What about the developers env?

Managing the proxy

worklight.properties ::

What is it?

Why should i use it?

<connectivity>
    <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
        <protocol>http</protocol>
	<domain>mydomain.com</domain>
	<port>1080</port>			
	<!--PROXY_SETTINGS-->
	<proxy>
	    <protocol>${adapter.name.proxy.protocol}</protocol>
	    <domain>${adapter.name.proxy.domain}</domain>
	    <port>${adapter.name.proxy.port}</port>
	</proxy>
     </connectionPolicy>
     <loadConstraints maxConcurrentConnectionsPerNode="10" />
</connectivity>

Proxy cannot be removed post-build

App Authenticity

Access Disabled - Worklight server does not test the Authenticity of the app

Enabled, servicing - Worklight server tests the Authenticity of the app; if it fails it services the device

Enabled, blocking - Worklight server tests the Authenticity of the app; if it fails it blocks the device

What is it? Why would I use it?

How do I enable it?

authenticationConfig.xml ::

application-descriptor.xml ::

<customSecurityTest name="AppAuth">
     <test realm="wl_remoteDisableRealm" /> 
     <test realm="wl_authenticityRealm" isInternalUserID="true"/> 
     <test realm="wl_deviceNoProvisioningRealm" isInternalDeviceID="true" /> 
</customSecurityTest>

<iphone bundleId="com.ibm.myapp" version="1.0" securityTest="AppAuth">
     <security> Additional settings here </security>
</iphone>

<android version="1.0" securityTest="AppAuth">
    <security>
        <publicSigningKey>Key extracted from keystore </publicSigningKey>
    </security>
</android>

Developer Edition? What about testing?

Adapter Authenticity

Why protect adapters?

exposed URL

protect downstream services

<customSecurityTest name="AdapterAuth">
    <test realm="wl_antiXSRFRealm"/>
    <test realm="wl_deviceNoProvisioningRealm" isInternalDeviceID="true" /> 
    <test realm="wl_anonymousUserRealm" isInternalUserID="true"/>  
</customSecurityTest>

authConfig.xml ::

Performance impact and back-out plan?

Lessons Learned

Building Apps

BUILDING WL WITH JENKINS

Build scripts & build time should be short

Jenkins exposes lots of $ENV_VARIABLES

Build Artefacts plugin / Build Tagging

Jenkins can execute bash, ant and other scripts

Keep Jenkins job config MINIMAL (script execution)

Multiple nodes --> Distributed builds

Separate your concerns

Build components separately

Android / iOS AND Worklight adapters

Do not house dev servers and build servers togther

WL Developer settings

Useful for controlling multiple envs

Gotcha - Custom build settings when moving to Production

Jenkins to support integration

Jenkins is more than just a build server!

Session Affinity

Multiple adapters connect to multiple backends

Single Adapter ::

Refactor all code into one mega adapter

Funnel all requests through one adapter

Manually manage the Session ::

// Before outbound request get session
var jSession = WL.Server.getActiveUser("SessionRealm").sessionId;

// after inbound request store session
sessionID = result.responseHeaders["X-JSESSIONID"];
WL.Server.setActiveUser("SessionRealm", { userId: username,
                                    secretData: "mySecret",
                                    sessionId: null
                                    });

How to really debug Worklight

1. Logging

In your server.xml ::

Or use Liberty Include feature for diff Env's ::

(In your build process)

cp / scp depending on what you need / where you are

<server>
   <logging traceSpecification=
         "com.worklight.adapters=FINEST:com.worklight.integration=FINEST"
          traceFileName="stdout" maxFileSize="20"  maxFiles="2" 
           traceFormat="BASIC" />
</server>

 <include optional="true" location="server.CI.xml"/>

2. Proxy Tooling

Write test to highlight failures and check them into SCM

Charles proxy

SSL proxy & iOS?

Android Proxy?

3. Chrome Dev tools

For Web elements in Android use Chrome's Android remote debugging plugin

Enable remote console on iOS and monitor through Xcode

Project Painpoints

Environments!

Consistency of Data between environments
Competition for resources & memory
Non representative test environments
Do the hard stuff first
Co-location of suppliers at critical project points
Use Good tools e.g. JIRA
Lack of test driven focus at times

Food for thought

Alternative CI tools?

Improved Testing?

Worklight Lessons Learned

Agenda

What we did?

What we learned?

Android & iOS App ::

App Features ::

Brief Background

The

App

The Parts

The Suppliers

Project Innovations

'Normal' Developement

CONTINUOUS INTEGRATION

Why do it?

THE TOOLS

TOOLS

TOOLS

TOOLS

IDEAL STEPS TO PRODUCTION

Pipelines & AppCenter

TESTING

ADAPTER URL

A Basic Test

Integration Test

Reporting and Automation

Lessons Learned

The Worklight Adapter

ADAPTER VERSIONING

The options Object { }

options object {}

Configuring Adapters

Managing the proxy

App Authenticity

How do I enable it?

Adapter Authenticity

Lessons Learned

Building Apps

BUILDING WL WITH JENKINS

Separate your concerns

WL Developer settings

Jenkins to support integration

Session Affinity

How to really debug Worklight

1. Logging

2. Proxy Tooling

3. Chrome Dev tools

Project Painpoints

Environments!

Food for thought

What is Worklight?