Presentation is loading. Please wait.

Presentation is loading. Please wait.

IHE Testing Tools An overview. The past (and current)  Mesa Tools  In house testing for Vendors  C++, Perl  Kudu  Connectathon management tool :

Similar presentations


Presentation on theme: "IHE Testing Tools An overview. The past (and current)  Mesa Tools  In house testing for Vendors  C++, Perl  Kudu  Connectathon management tool :"— Presentation transcript:

1 IHE Testing Tools An overview

2 The past (and current)  Mesa Tools  In house testing for Vendors  C++, Perl  Kudu  Connectathon management tool :  kind of speed dating software. Allows vendors to enter configuration and find test partners  Allow sponsor to control connectathon’s progress  PHP, Postgresql DB

3 The Future (Gazelle)  Improve quality of testing  Introducing conformance testing where we only had interoperability testing  Unify Kudu and Mesa into one tool  Target to Vendors, Users and Sponsors  Opensource  Open and evolving architecture

4 Interoperability / Conformance 22/05/08Projet IHE-Dev Inria Rennes 4 Specifications/Standards Implementation A Vendor A Implementation B Vendor B Interoperability testing Conformance Testing

5 Gazelle

6 Gazelle Architecture Proxy System Under Test Network Gazelle Test Engine Control Configuration Info Feedback External Validation Services Tests Scenario Gazelle Actor (Simulators) Gazelle Control System External Validation Services External Validation Services External Validation Services Gazelle Actor (Simulators) Gazelle Actor (Simulators) Gazelle Actor (Simulators) Gazelle Actor (Simulators) System Under Test Database 22/05/08Projet IHE-Dev Inria Rennes 6

7 Proxy

8 Requirements  Capture messages exchanged between test participants  Shall be neutral : Non destructive message capture  Transmit captured messages to the Test Engine for further processing (EVS)  Provide information about sender and recipient when available 22/05/08Projet IHE-Dev Inria Rennes 8

9 Proxy Design SUTa Proxy SIMU2 Port 2004 SIMU1 Port 104 SUT2 Port 104, 2000 SUT1 Port 2200 9201 9202 9203 9204 9205 Test Engine

10 Design  Need to open a port for each responder  Transaction initiator may not know the responder real port  Proxy knows the responder based on the port used  Useful to provide more information that port and ip  Responder port may be mapped with more that one port on the proxy  Solution to isolate messages in the context of a test

11 SUT1 participating to 2 tests SUTa Proxy SUT1 Port 2200 9201 9202 9203 9204 9205 SUTb Test Engine

12 SUT1 participating to 2 tests SUTa Proxy 9201 9202 9203 9204 9205 SUTb Test Engine SUT1 Actor A and Actor B share the same port Proxy maps an individual port for each config

13 Proxy Configuration Proxy SUT3 SUT2 SUT1 Control System Test Engine Simulator 1 Simulator 2

14 Proxy Environment Overview 14 Daemon EVS mirth_input hl7_message_validation SUT1SUT2 1 3 4 5 6 7 2 Proxy

15 Proxy : First Experience  Proxy developed for the Oxford C.A.T  Capture of HL7 V2 messages only  Used under real conditions in Oxford  Messages transmitted to Kudu for call to EVS  NIST EVS  INRIA EVS  Usage of the proxy not required but recommended  Message captured and validation results available to participants through Kudu. 22/05/08Projet IHE-Dev Inria Rennes 15

16 Proxy  Concept validated  Enable gathering of sample messages for validation of the EVS services  Improvements following Oxford C.A.T.  Capture of ACK messages  Extension to other protocols  XDS Messages  HL7 V3  Dicom (more complex) 22/05/08Projet IHE-Dev Inria Rennes 16

17 EVS External Validation Services

18 Gazelle Architecture Proxy System Under Test Network Gazelle Test Engine Control Configuration Info Feedback External Validation Services Tests Scenario Gazelle Actor (Simulators) Gazelle Control System External Validation Services External Validation Services External Validation Services Gazelle Actor (Simulators) Gazelle Actor (Simulators) Gazelle Actor (Simulators) Gazelle Actor (Simulators) System Under Test Database 22/05/08Projet IHE-Dev Inria Rennes 18

19 Specification Requirement  Use of Webservices  Definition of the API  Arguments, methods  Definition of XSD and XSL for arguments  Choice of MTOM for the transport of large objects like Dicom 22/05/08Projet IHE-Dev Inria Rennes 19

20 EVS  Dicom :  DVTK based  Dicom3tools based  HL7 :  NIST  INRIA  IHE-J ?  CDA  NIST publish Schematron 22/05/08Projet IHE-Dev Inria Rennes 20

21 HL7 EVS  2 EVS available for the moment  NIST  INRIA  Validation based on HL7 Message Profiles  More than 140 Message profiles defined for exisiting IHE transactions  Profiles available from Kudu TF section while waiting for Gazelle Message profile repository 22/05/08Projet IHE-Dev Inria Rennes 21

22 Test Engine

23 22/05/08Projet IHE-Dev Inria Rennes 23 Simulator System Under Test Test Case Test Reports Test Case Test Reports Loggin g System Under Test Simulator ProxyEVS EVS Mgr Proxy Mgr TF Gazelle Database Test Engine

24  Mock up  TF -> ebXML-BP -> BPEL -> gestion des différents composants 22/05/08Projet IHE-Dev Inria Rennes 24

25 Product Registry  Application Web  Objectifs : recherche de produits qui implémentent des profils d’intégration IHE  Sous composant de gazelle utilisant un sous ensemble des modules de gazelle  Permet de tester les choix, le modèle  Développé à Rennes 22/05/08Projet IHE-Dev Inria Rennes 25

26 Gazelle Registration  Se base sur l’expérience du Product Registry  Portage de la partie enregistrement pour le connect-a-thon dans Gazelle  Doit être fonctionnel pour l’été (C.A.T NA)  Réalisé à Saint Louis et Rennes 22/05/08Projet IHE-Dev Inria Rennes 26

27 Mgt Tools Project Management

28 Gazelle Project Management  Forge for source management  Use of


Download ppt "IHE Testing Tools An overview. The past (and current)  Mesa Tools  In house testing for Vendors  C++, Perl  Kudu  Connectathon management tool :"

Similar presentations


Ads by Google