Transcript Insert title here - Gaming Standards Association

How to speed up the implementation of
GSA standards into new products
Backward Compatibility,
Interoperability and Testing
May 2010
Green Valley Ranch - Las Vegas, NV
Ales Gornjec, Hermes SoftLab
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
Slide 2
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
Slide 3
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)
Slide 4
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
Slide 5
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
Slide 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
Slide 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
Slide 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.
Slide 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
Slide 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
Slide 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
Slide 13
G2S Host simulator’s WWF script
Workflow
tracker allows
test automation
and tracks the
execution of
workflow
scripts
Slide 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
Slide 15
Steps to create Workflow
Step 1:
Drag and drop
appropriate
activities on
workflow
designer
Slide 17
Steps to create Workflow
Step 2:
Fill Property
grid for each
activity – bind
property to
another
property or
insert text
(class,
command,
elements,
attributes)
Slide 18
Testing time comparison
phase
design
automatic test creation
and verification
manual testing
automated
testing
and documentation (1-2 h)
8h
single cycle execution
20 minutes
1 min
total execution time per
100 test cycles
2045 minutes
625 minutes
errors in execution (need
to repeat the test)
50
1
Slide 19
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).
Slide 20
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
Slide 21
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>
Slide 22
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.
Slide 23
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
Slide 24
Questions?
Slide 25