1. Backward Compatibility, Interoperability and Testing May 2010 Green Valley Ranch - Las Vegas, NV Ales Gornjec, Hermes SoftLab How to speed up the implementation of GSA standards into new products

2. Slide 2 Agenda  G2S and S2S versions and impacts  Surviving with multiple versions of protocol  Interoperability  Changes introduced through clarifications in G2S 2.0  Strategies in solving and avoiding interoperability issues  Compliance with protocol specifications

3. Slide 3 Protocol versions  G2S  First released in 2006  Since we have seen one major release and several updates /clarifications  S2S  First release in 2004  Several updates and new releases were published  Multiple versions already implemented and deployed  New (major) versions are released every second year  New functionalities (integrated extensions)  Rearranged classes  Clarifications in gray areas  Support for multiple versions needed in both EGMs and systems  Strategy needed to keep interoperability at reasonable level

4. Slide 4 Multiple version requirements  EGMs  Costly to implement support for multiple versions of G2S to work simultaneously  Multiple versions could be supported and treated as separate protocols  EGM must be configured to start with particular version  Host systems  Reasonable to expect not all EGMs on floor support the same G2S version  Support for multiple simultaneous versions is needed  Extensions add complexity for multiple version support  Not a clear way to detect what peer supports  G2S has optional support for namespace negotiation (from v2.0)

5. Slide 5 G2S Multi-version support strategy  EGMs  Must stick with protocol and extension specification as much as possible  Avoid shortcuts in implementation  Detect and process errors correctly  Hard to hot fix due to certification constraints  Host  Should be able to support different versions and  Different collections of extensions  Use fall-back strategy (ask for cabinet instead of device meters)  Be tolerant to inconsistencies (when processing EGM messages)  Be compliant to specifications (when composing own messages)  More possibilities to deploy hot fixes  Field effect

6. Slide 6 Near future situation

7. Slide 7 Interoperability problems  Possible impacts  No communication – few or none messages exchanged  Messages exchanged, but lots of errors reported  Some functionality not usable (some G2S classes not operable)  Consistency and quality of delivered data  Several steps needed to resolve the issue  Examine communication logs  Scan communication and analyse messages (more complicated with encrypted communication)  Analyze message flow  Deduce problem location and nature  Plan how to fix and resolve the issue

8. Slide 8 Interoperability testing and validation  Scope:  Usually starts with single entities on both sides (EGM & system)  The goal for both sides is to work with multiple products  Interoperability LABs needed to tests such combinations  Common test tools help in pre-system test phases  Possible directions:  Follow the leader (first adopter)  Establish community agreement for common interoperability testing  Strong push from one major operator

9. Slide 9 G2S 1.0.3 to G2S 2.0  Some classes changed significantly like communications class  Additional request-response pairs  Additional functionality (namespace negotiation)  Additional (optional) attributes  Several clarifications on how some functionalities must be implemented  Some gray areas removed  Portions of protocol stack needed rework  Major products still based on 1.0.3

10. Slide 10 G2S 2.0  Some changes in specification urged to change the implementation of stack and way of integration  Examples:  Generation of event transactionIds changed (auto-generated in 1.0.3; derived from context in 2.0)  Implementation changed: eventLogEntry.transactionId must be set by the device that reports the event. EventLog will not create and assign transactionId any more.  Relation between G2S device states (lock, disable) and EGM global state changed.

11. Slide 11 Testing  GSA certification checks protocol implementation and integration on message level  To remove interoperability issues, more complex scenarios are needed:  Complex real life interaction  EGM state machine changes (service, menus, configuration)  Test automation is crucial for:  Keeping cost reasonable  Efficient regression testing  Performance testing (hosts testing)  Duration testing

12. Slide 12 HSL test automation based on WWF  G2S Host simulator  Allows test automation;  Test scripts are based on Windows Workflows Foundation (WWF)  Windows Workflows Foundation (WWF)  Provides displaying, editing and creating of workflows  Alternative text editors for scripts creation  Tracks the execution of workflow scripts

13. Slide 13 G2S Host simulator’s WWF script Workflow designer enables:  displaying,  editing and  creating of various test scenarios based on the Embedded Windows Workflow Foundation Script Editor

14. Slide 14 G2S Host simulator’s WWF script Workflow tracker allows test automation and tracks the execution of workflow scripts

15. Slide 15 G2S Workflow Activities  Send: sending messages to the EGM  Receive: receiving messages from the EGM and filtering for individual classes and devices  ReceiveEventReport: filtering messages to different events  Validation: validating messages received by the EGM. It can validate a single or multiple attributes  Transform:  various transformations of XML messages  setting sesssionIDs, commandIDs,  setting date and /or time,  etc. before the messages are sent

16. Slide 16

17. Slide 17 Step 1: Drag and drop appropriate activities on workflow designer Steps to create Workflow

18. Slide 18 Steps to create Workflow Step 2: Fill Property grid for each activity – bind property to another property or insert text (class, command, elements, attributes)

19. Slide 19 Testing time comparison phasemanual testingautomated testing designand documentation (1-2 h) automatic test creation and verification 8 h single cycle execution20 minutes1 min total execution time per 100 test cycles 2045 minutes625 minutes errors in execution (need to repeat the test) 501

20. Slide 20 Workflow execution tracking - example To execute the workflow:  Select desired workflow when communication between host and EGM is established. To track the worklfow  Tracking of the workflow can be done via Workflow tracker’s Tracking Channel (in text form) or Tracking Viewer (graphic form).

21. Slide 21 Interoperability: XML name prefix usage  Problem:  W3C XML specification allows strings for namespace prefixes to be chosen by the implementation.  W3C XML allows global namespace to be defined without explicit prefix  XML generators may use predefined or auto generated prefixes.  XML parser should handle any prefix that was used by sender.  Expecting prefixes to be used in particular way in receiver will cause interoperability problems.  Impact:  High: Protocol stacks are not interoperable.  Strategy/Solution:  Simple: By default use auto generated prefixes (optimized for size)  Medium: Possibility to configure prefixes (if not auto-generated)  Medium: Tweak your XML generator to emit prefixes in particular way

22. Slide 22 Example of valid XMLs  One system might send: <s2sAck xmlns:v1="http://www.gamingstandards.com/s2s/schemas/v1.2.6/" v1:dateTimeSent="2010-04-14T12:21:07.728+03:00" v1:fromSystem="http://1.2.3.4:8082/S2S_1" v1:messageId="78" v1:toSystem="http://4.3.2.1:12345/S2S"/>  Another might expect: <v1:s2sAck v1:dateTimeSent="2010-04-14T12:21:07.728+03:00" v1:fromSystem="http://1.2.3.4:8082/S2S_1" v1:messageId="78" v1:toSystem="http://4.3.2.1:12345/S2S"/>

23. Slide 23 Interoperability: response to setCabinetState  G2S specification allows EGM to respond immediately or when actual change of state occurs  Problem:  Such flexibility in EGM implementation can complicate host implementation significantly  Impact:  Medium: Inconsistency of cabinetState information at host side  Strategy/Solution:  Complex: Implement more complex state machine on host side and subscribe to events.

24. Slide 24 Interoperability: S2S Wildcard behaviour  S2S allows to use wildcards for selecting meters  In accountingMeter subscriptions  In event subscriptions  In on demand requests  Problem:  Host/server might not have enough information for S2S client requests  Impact:  High: inconsistent data may be delivered  Strategy/Solution:  Complex: Upgrade implementation to newer (latest) version  Medium: follow explanation from latest version on existing product  Host (edge) implementation and data collection strategy from EGM is adjusted to satisfy S2S needs

25. Slide 25 Questions?