tips for developing and testing ibm hats applications
TRANSCRIPT
Tips for Developing and Testing IBM Host Access Transformation Services ApplicationsKenny Smith, Strongback Consulting
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 athttp://blog.strongbackconsulting.com
Socialize with us on Facebook & LinkedIn http://www.facebook.com/StrongbackConsulting
http://www.linkedin.com/company/290754
Developing HATS appsRecipes for success
3
Overview of Development Cycle
Uniquely tailor the user
experienceCustom widgets,
componentsi18n
Consume web services
Make DB calls3 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
4
5
Basic deployment
• Keep It Simple• Basic out of the box implementation• Time: an afternoon
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
7
Moderate customization
• Macros• Producing Web services• Consuming web services• More screen customizations• Some custom Javascript functions• Integration with Portal• Mobile Application
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
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
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
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
Tips for using SCM with HATSHow to avoid throwing coffee at your monitor
12
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
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
TestingUnit Testing, Functional Testing, and Performance Testing
16
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
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
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!
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
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
22
Record Terminal First
• RFT can test 3270/5250• use the same data to test
HATS
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
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
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
26
How Mocking Works:
host screen i/z Host
Mock this
HATSEngine
27
Normal Operation
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() methodis called
HostScreen hsr = readHostScreenFromFile(“myscreen.hsr”); Mockito.when(blInfo.getHostScreen()).thenReturn(hsr);
29
Screen Captures: XML under the covers
30
The HostScreen Object
• Two Ways to Instantiate:• HostScreen hostScreen = blInfo.getHostScreen();• HostScreen hostscreen = new HostScreen(screencapture);
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; }
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()); }
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
34
Create a User Library for Mockito
• Window -> Preferences• Java -> Build Path -> User Libraries• Add JavaDoc also!
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
36
Mockito is well documented!
• Make sure you add the Javadoc location to your User Library• Excellent example of GOOD documentation!
37
DEMO
Getting Started with XMLUnitHow to setup your environment and write your first test
38
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)
http://www.xmlunit.org/
40
Setup your first test
public class ApplicationHAPTest extends XMLTestCase {
@Beforepublic 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);
. . . }
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); }
42
Testing the HATS Project Settings (Application.hap)@Testpublic 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."); } }
12
3
43
DEMO
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 athttp://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!!