Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tips for Developing and Testing IBM HATS Applications

3,386 views

Published on

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.

Published in: Technology
  • Login to see the comments

  • Be the first to like this

Tips for Developing and Testing IBM HATS Applications

  1. 1. Tips for Developing and Testing IBM Host Access Transformation Services Applications Kenny Smith, Strongback Consulting
  2. 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. 3. Developing HATS apps Recipes for success 2
  4. 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. 5. Basic deployment • Keep It Simple • Basic out of the box implementation • Time: an afternoon 4
  6. 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. 7. Moderate customization • Macros • Producing Web services • Consuming web services • More screen customizations • Some custom Javascript functions • Integration with Portal • Mobile Application 6
  8. 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. 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. 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. 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. 12. Tips for using SCM with HATS How to avoid throwing coffee at your monitor 11
  13. 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. 14. Avoid aggravation: Ignore these files • All log files HATS_EAR/logs • Web Content/WEB-INF/profiles/resourceUpdate.sts
  15. 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. 16. Testing Unit Testing, Functional Testing, and Performance Testing 15
  17. 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. 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. 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. 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. 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. 22. Record Terminal First • RFT can test 3270/5250 • use the same data to test HATS 21
  23. 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. 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. 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. 26. How Mocking Works: 25 host screen i/z Host Mock this HATS Engine
  27. 27. Normal Operation 26 Class under Test Dependent Class (IBusinessLogicInformation )
  28. 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. 29. Screen Captures: XML under the covers 28
  30. 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. 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. 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. 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. 34. Create a User Library for Mockito • Window -> Preferences • Java -> Build Path -> User Libraries • Add JavaDoc also! 33
  35. 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. 36. Mockito is well documented! • Make sure you add the Javadoc location to your User Library • Excellent example of GOOD documentation! 35
  37. 37. 36
  38. 38. Getting Started with XMLUnit How to setup your environment and write your first test 37
  39. 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. 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. 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. 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. 43. 42
  44. 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!!

×