IBM Rational Host Access Transformation Services (HATS) can dynamically transform your terminal-based applications into rich web pages. It is highly customizable and built on Java EE technology. We'll discuss some lessons learned from a very (very) complex HATS engagement. We'll discuss proper development strategies, and how to distribute workload across team members. We'll introduce a novel approach to unit testing advanced customizations using JUnit, and will also talk about how to address functional testing.

1. Tips for Developing and Testing
IBM Host Access Transformation
Services Applications
Kenny Smith, Strongback Consulting

2. About Strongback Consulting
• IBM Advanced Business Partner
– Rational, WebSphere, ICS SVP certified
– Strongly focused on DevOps, Enterprise Modernization, and application infrastructure
– Key Industries Served: Finance, Insurance, Travel, Logistics, Healthcare, Manufacturing, Government
– Rational Design Partner for HATS and other Rational enterprise modernization technologies
Discover us at:
http://www.strongback.us
Subscribe to us at
http://blog.strongbackconsulting.com
Socialize with us on Facebook & LinkedIn
http://www.facebook.com/StrongbackConsulting
http://www.linkedin.com/company/290754

3. Developing HATS apps
Recipes for success
2

4. Overview of Development Cycle
Uniquely
tailor the user
experience
Custom
widgets,
components
i18n
Consume
web services
Make DB
calls
3 months +
Add Complex
Customizations
Customize
some
screens
Implement
macros
Provide Web
Services
1-2 month
Moderate
Customization
Apply your
own skin
Modify
default
rendering
rules
< 1 week
Custom
Template
Out of the
box rendering
Minimal
changes
< 4 hours
Default
3

5. Basic deployment
• Keep It Simple
• Basic out of the box implementation
• Time: an afternoon
4

6. Modest customization
• “Skin” it to make it look more like your
own company site
• Global Rules and Text Replacement
– Calendar pickers
– Radio buttons for data entry
• Customize only the most heavily used
screens
– Tweak subfiles and tables
– Add navigational links
5

7. Moderate customization
• Macros
• Producing Web services
• Consuming web services
• More screen customizations
• Some custom Javascript functions
• Integration with Portal
• Mobile Application
6

8. Heavy customization
• Gung ho!
• Create Custom Widgets and
Components (i18n)
• Connect to databases
• Deep screen customizations
• Integration with ERP or CRM
• Dig under the hood and control at a
Java API level
– Custom screen recognition
– Custom macro actions
– Custom business logic
7

9. General Guidelines For Renderings
• Do the simplest thing that can possibly work
• Customize by exception
– Let default rendering do the work
– Focus on getting Default Rendering rules working first
• Don’t edit the HATS Javascript files
– Put your customizations in separate .JS files
• Edit or copy from the OOTB the CSS files
– Use the OOTB class names
• Accept that sometimes a quick fix in RPG/COBOL is easier than toiling
over a crappy green screen issue
8

10. General Rules for Web Services and I.O.’s
• Develop macro thoroughly
• Build "Happy path" first
• Develop and account for "sad paths" (could be many of them)
• Don't generate web service stubs until you've got the macro solid!
• You can edit the I.O. template file if it does not generate what you need
9

11. If you must do mockups
• When doing big customizations….
• Write your mockups in plain HTML
• Don’t do Photoshop or image based mockups
• HTML can be directly used as stubs for the template & screen
customizations
10

12. Tips for using SCM with HATS
How to avoid throwing coffee at your monitor
11

13. General Tips
• Team development in a single HATS app can be a challenge
• Project settings document will require careful merging
– WEB-INF/profiles/application.hap
• Some files will drive you nuts – they change every save … and don’t
need to be versioned
• Use xmlUnit to unit test the application.hap – require a unit test run
before code delivery
**This is a setting that can be enforced in Team Concert
*** slides coming up on these details later

14. Avoid aggravation: Ignore these files
• All log files HATS_EAR/logs
• Web Content/WEB-INF/profiles/resourceUpdate.sts

15. Use good naming conventions
• Prefix all artifacts with a screen identifier
• Package naming
– [com | gov | net].<mycompany>.<appname>.<type>
• Example:
– com.strongback.crm.hats.domain
– com.strongback.crm.hats.io
– com.strongback.crm.hats.businessLogic
– com.strongback.crm.hats.widgets
– test.strongback.crm.hats.businessLogic
14

16. Testing
Unit Testing, Functional Testing, and Performance Testing
15

17. Types of Testing
• Policy (Accessibility)
• Security
• Performance
– Load, stress
– Can be automated
• Functional
– a.k.a. “Black Box” or User Acceptance Test
• Unit
– Written by developer, run by developer
– Junit, xmlUnit
– Always automated, and part of continuous build cycle
16

18. Performance Testing
• Tests should look at JVM GC over time
– use WAS’ performance monitor tools to collect
– Look at heap utilization, garbage collection stats
• Test script should be a subset of real application usage, and timing
• DON’T expect HATS interaction time to be as fast as an emulator!!
– Emulator: Direct connection between user and host
– HATS: 1 connection from host to WAS, 1 from WAS to user
17

19. What adversely affects performance?
• Excessive screen customizations (>100)
• Poorly written custom Java code
• Compression filter *
• Database calls
• Insufficient Memory in WAS
• Poorly resourced LPAR
• The perceived time between screens is the key indicator to watch for!
18

20. Performance Testing Gotcha
• Compression Filter
– Designed to compress HTTP response
• Will cause JVM crashes if not
configured
– Compression is one of the most expensive
tasks a CPU can do
– Default size is 0KB
• Either disable, or set parameter > 1KB
19

21. Functional Testing
• Tools: RFT, Selenium
• 3 priorities
– Test screen customizations first
– Test screens with high usage patterns next
– Test a subset of default rendered screens
• Think subfiles, tables, calendar pickers, etc.
• Reuse test data!
– Same RFT data can be used for pure terminal emulator tests
– IBM Test Data Manager
20

22. Record Terminal First
• RFT can test 3270/5250
• use the same data to test
HATS
21

23. Unit Testing – what is it?
• Developer written to test other code
• Can be automated
• Results in a pass or fail
• Example:
– Class to test the XML of the Project Settings
document
– Class to test a custom widget, or custom
component
22

24. Unit Testing: Why its difficult
• Custom Java classes that use the HATS API
– Business Logic
– Screen Recognition
– Integration Objects
• Usual methods invoke the HATS Runtime Engine
– i.e. requires a live connection
23
public static void execute( IBusinessLogicInformation blInfo) {….}
This gets
populated by the
runtime
environment

25. Introducing Mocking and Stubbing
• http://mockito.org/
• Mocking framework that creates a mock of a system
• i.e. it mocks the behavior of the host
24

26. How Mocking Works:
25
host
screen
i/z Host
Mock this
HATS
Engine

27. Normal Operation
26
Class under
Test
Dependent Class
(IBusinessLogicInformation )

28. Stubbing
• Stubs return fixed results on each call
• In this case, its fixed to return the desired
screen when its getHostScreen() method
is called
27
HostScreen hsr = readHostScreenFromFile(“myscreen.hsr”);
Mockito.when(blInfo.getHostScreen()).thenReturn(hsr);

29. Screen Captures: XML under the covers
28

30. The HostScreen Object
• Two Ways to Instantiate:
• HostScreen hostScreen = blInfo.getHostScreen();
• HostScreen hostscreen = new HostScreen(screencapture);
29
This constructor
requires an XML
file!

31. Create a convenience method to read the file
Read the screen capture in as an XML Document, then pass to the HostScreen constructor
protected HostScreen readHostScreenFromFile(String screenFileName)
throws UnsupportedEncodingException, ParserConfigurationException, IOException
, SAXException {
URL url=this.getClass().getResource(screenFileName);
String file= URLDecoder.decode(url.getFile(), "UTF-8");
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document screencapture = builder.parse(file);
HostScreen hostscreen = new HostScreen(screencapture);
return hostscreen;
}
30

32. Now, mock and stub
@Mock
protected IBusinessLogicInformation blInfo;
@Test
public void testOperatorNameSetsCorrectValue() throws SAXException, IOException,
ParserConfigurationException {
OperatorName opname = new OperatorName();
HostScreen hostscreen = readHostScreenFromFile(SCREEN_MAIN_MENU);
Mockito.when(blInfo.getHostScreen()).thenReturn(hostscreen);
Hashtable hastableGVs = new Hashtable(1);
Mockito.when(blInfo.getGlobalVariables()).thenReturn(hastableGVs);
opname.execute(blInfo);
com.ibm.hats.common.GlobalVariable operator = (com.ibm.hats.common.GlobalVariable)
hastableGVs.get("operatorId");
assertEquals("KENNY SMITH (ASATKSM)", operator.getString().trim());
}
31
Mock the
Business
Logic Object
This B.L. object gets the
operator name from
specific coordinates and
sets a global variable
Stub its
getHostScreen()
method

33. Advantages of Mocking
• Repeatable
– Do not have to reset data after a test
• Does not require connection to the system
• Allows integration with a build system
– i.e. Jazz Build Engine, Hudson, Jenkins, etc.
• Faster testing time
• No navigation required
• Can capture multiple test conditions
– Different screen capture for each screen’s possible output
32

34. Create a User Library for Mockito
• Window -> Preferences
• Java -> Build Path -> User Libraries
• Add JavaDoc also!
33

35. Setup your HATS Project for Unit Testing
• Create an empty class com.ibm.eNetwork.HOD.ScreenHistory
– This is referenced by HATS program code, but is never used.
– Junit code will not run without
• Download Mockito
• Add Junit library to build path
• Add mockito library to build path
34

36. Mockito is well documented!
• Make sure you add the Javadoc location to your User Library
• Excellent example of GOOD documentation!
35

37. 36

38. Getting Started with XMLUnit
How to setup your environment and write your first test
37

39. xmlUnit
• Test xml based files
• Uses Xpath under the covers
• Key Files to test:
– application.hap (project settings document)
– macro files (are all XML under the hood)
38
http://www.xmlunit.org/

40. Setup your first test
public class ApplicationHAPTest extends XMLTestCase {
@Before
public void setup() {
System.setProperty("javax.xml.parsers.DocumentBuilderFactory",
"org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
System.setProperty("javax.xml.parsers.SAXParserFactory",
"org.apache.xerces.jaxp.SAXParserFactoryImpl");
System.setProperty("javax.xml.transform.TransformerFactory",
"org.apache.xalan.processor.TransformerFactoryImpl");
XMLUnit.setIgnoreWhitespace(true);
. . .
}
39

41. Setup method to find your XML files
private void instantiateCommon() throws IOException, SAXException {
String dirfile = System.getProperty("user.dir") + HAP;
try {
// running on a local laptop
fromXML = new File(dirfile);
reader = new FileReader(fromXML);
} catch (Exception e) {
// running on the build server
fromXML = new File(“/home/my/workspace”+HAP);
reader = new FileReader(fromXML);
}
fromSource = new InputSource(reader);
hapdoc = XMLUnit.buildTestDocument(fromSource);
}
40

42. Testing the HATS Project Settings (Application.hap)
@Test
public void testCriticalEventsAreListedInProperOrder() {
String resetCookieState =
"/application/eventPriority/event[1][@name=‘resetCookieState']";
String SalesForceIntegration =
"/application/eventPriority/event[2][@name=‘SalesForceIntegration']";
String MainMenu =
"/application/eventPriority/event[3][@name='MainMenu']";
try {
instantiateCommon();
assertXpathExists(resetCookieState , hapdoc);
assertXpathExists(SalesForceIntegration, hapdoc);
assertXpathExists(MainMenu, hapdoc);
} catch (Exception e) {
e.printStackTrace();
fail("The event priority list has been changed. Please ensure
the correct order.");
} } 41
1
2
3

43. 42

44. About Strongback Consulting
• IBM Advanced Business Partner
– Rational, WebSphere, ICS SVP certified
– Strongly focused on DevOps, Enterprise Modernization, and application infrastructure
– Key Industries Served: Finance, Insurance, Travel, Logistics, Healthcare, Manufacturing, Government
– Rational Design Partner for HATS and other Rational enterprise modernization technologies
Discover us at:
http://www.strongback.us
Subscribe to us at
http://blog.strongbackconsulting.com
Socialize with us on Facebook & LinkedIn
http://www.facebook.com/StrongbackConsulting
http://www.linkedin.com/company/290754
Find this presentation
and sample code
here!!