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?
What is Worklight?
Worklight Lessons Learned
By Donal Spring
Worklight Lessons Learned
Slide deck demonstrating some of the lessons learned from delivering a Consumer facing Worklight App
