1 / 23

Backward Compatibility, Interoperability and Testing May 2010 Green Valley Ranch - Las Vegas, NV Ales Gornjec, Hermes

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. Agenda. G2S and S2S versions and impacts Surviving with multiple versions of protocol

keala
Télécharger la présentation

Backward Compatibility, Interoperability and Testing May 2010 Green Valley Ranch - Las Vegas, NV Ales Gornjec, Hermes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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. 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. 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. 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

  7. 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

  8. 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

  9. 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.

  10. 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

  11. 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

  12. 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

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

  14. 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

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

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

  17. Testing time comparison

  18. 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).

  19. 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

  20. Example of valid XMLs • One system might send: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <s2sMessage xmlns="http://www.gamingstandards.com/s2s/schemas/v1.2.6/">   <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"/> </s2sMessage> • Another might expect: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <v1:s2sMessage xmlns:v1="http://www.gamingstandards.com/s2s/schemas/v1.2.6/">   <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"/> </v1:s2sMessage>

  21. 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.

  22. 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

  23. Questions?

More Related