1. AR meeting Esrin, 26. January 2011 Slide 1 Ordering Services for EO Products Abstract (ATS) and Executable (ETS) Test Suite HMA FollowOn – Task 4 AR Meeting at Esrin 26 January 2011 Uwe Voges, con terra GmbH u.voges@conterra.de

2. AR meeting Esrin, 26. January 2011 Slide 2   Introduction   General Model   Conformance Classes   Test ‘Scenarios’   Test Cases   Results   Next Steps   Issues Agenda

3. AR meeting Esrin, 26. January 2011 Slide 3   EOOrderService class: associated with 5 classes, each with one or more operations   Each real instance of the EO- OrderService must implement two or more associated classes A compliant OrderServer shall implement OGCService and EOOrderCore and can implement additional classes General Order Model

4. AR meeting Esrin, 26. January 2011 Slide 4   EO Products can be ordered in different ways.   Main differences grouped as follows:   Type of product definition Product Order: from archive, defining products by identifier and options Tasking Order: acquisition of future products by providing identifier of a Tasking Request issued through a companion SPS server Subscription Order: specifying the periodical delivery of loosely defined products   Type of delivery: OnlineDataAccess (online access point defined by server), OnlineDataDelivery (online access point defined by client), MediaDelivery   Support of optional operations: e.g. Cancel, GetQuotation   Asynch behaviour: e.g. async Cancellation, async Submit,   Different Requirement Classes have been defined for the different features   Core   For each of the identified order types   For optional functions Requirement Classes

5. AR meeting Esrin, 26. January 2011 Slide 5   Implementations are expected to comply with at least one of ProductOrder, SubscriptionOrder, TaskingOrder and optionally with one or more of the other classes   A server which complies only with Core is just a skeleton accepting and returning valid messages, but doing actually nothing   Relationships between the defined Requirement Classes: Requirement Classes  inheritance relationships represents inheritance of requirements from super class  e.g.: ProductOrder class defines specific require- ments but includes require- ments of Core

6. AR meeting Esrin, 26. January 2011 Slide 6   Conformance classes defined 1:1 with respect to Requirement Classes:   each conformance class in charge of validating corresponding Requirement Class: ATS - Conformance Classes

7. AR meeting Esrin, 26. January 2011 Slide 7   Examples:   CC Core   is in charge of verifying the compliance of the Order Server under test with respect to the Core Requirement Class, which includes the basic functions that every Order Server shall implement.   CC ProductOrder   verifying the compliance of the Order Server under test with respect to the ProductOrder Requirement Class, which specifies all requirements an Order Server has to comply with for claiming the support of Ordering for Earth Observation Products   CC SceneSelection   verifying the compliance of the Order Server under test with respect to the SceneSelection Requirement Class, which specifies all requirements an Order Server has to comply with for claiming the support of Ordering for Earth Observation Products with scene selection options ATS - Conformance Classes

8. AR meeting Esrin, 26. January 2011 Slide 8   As full compliance with all CC´s is very difficult to achieve, the following groupings of compliances are practically relevant:   An Order Server supporting product ordering for scientific users should comply with:   Core   MediaDelivery   ProductOrder   SceneSelection   An Optionally it should support also on-line delivery: OnlineDataAccess OnlineDataDelivery ATS - Conformance Classes

9. AR meeting Esrin, 26. January 2011 Slide 9   An Order Server supporting product ordering for commercial users should comply with:   Core   MediaDelivery   ProductOrder   SceneSelection   Quotation and at least one of: QuotationAsync QuotationMonitoring QuotationOffLine QuotationSync   Optionally it should support also on-line delivery: OnlineDataAccess OnlineDataDelivery ATS - Conformance Classes

10. AR meeting Esrin, 26. January 2011 Slide 10   Each Conformance Class is composed of a set of Conformance Tests, each verifying one or more requirements of the corresponding Requirements Class   Each Conformance Class covers all requirements of the corresponding Requirements Class.   To be noted: Conformance Tests have “temporal dependencies”:   for running one test another specific tests might be needed (e.g. to test order status at least one order needs to be created in the Order Server by Submitting an order). Then: the tests specified in a Conformance Class must be executed in the order they are specified in the document; The tests of a Conformance Class can be started only if the tests of the parent class have been completed. ATS - Conformance Classes

11. AR meeting Esrin, 26. January 2011 Slide 11   Test Cases represent execution of a service call and testing of the service results   Test Case looks like this: ATS - Conformance Test Cases

12. AR meeting Esrin, 26. January 2011 12  Executable Test Suite (ETS): „Implements“ ATC of ATS  Includes test cases for operations supported by OPGW  GetCapabilities  GetOptions (for predefined Coll/PO/Sub/SPS)  Submit  GetStatus  DescribeResultAccess Submit / GetStatus / DescribeResultAccess tested with „temporal dependencies“ ›No communication with Catalogues or SPS (Product-ID must a priori be known) ›Submit ›GetStatus used within an Order Scenario following a Submit request ›DescribeResultAccess (optionally) follows GetStatus test cases  +Cancel (although not supported by OPGW) tested with „temporal dependencies“ tested within Scenario  Supports version 0.9.6 => equals to 1.0.0  Real tests with older version (0.9.4) against EUMETSAT implementation Executable Test Suite (ETS)

13. AR meeting Esrin, 26. January 2011 13  Testing with temporal dependencies  GetStatus with dependency on Submit- and Cancel-requests with repeat-test, to test within a timeframe if status = successful  Example: ETS – temporal dependencies

14. AR meeting Esrin, 26. January 2011 14 ETS - Tests

15. AR meeting Esrin, 26. January 2011 15  The following figure describes the structure of the.ctl-scripts: CC_EOOrderCore.ctl main.ctl EOOrderCoreGetCapabilities.ctl EOOrderCoreGetOptions.ctl EOOrderCoreSubmitGetStatusDescResult.ctl Java_functions.ctl ATS A.3.1.1, A.3.1.2 ATS A.3.1.3, A.3.1.4 ATS A.3.1.5 ---> A.3.1.6 EOOrderCoreGetStatus.ctlATS A.3.1.10 ---> A.3.1.13 EOOrderDescribeResultAccess.ctlATS A.3.3.1 call-test call-function Implements test case CC_EOOrderCancel.ctl ATS A.3.4.1 A.3.4.2 ETS – ctl scripts

16. AR meeting Esrin, 26. January 2011 16  the requests are outsourced in separate “request-message-files” load file ETS – ctl scripts

17. AR meeting Esrin, 26. January 2011 17  Because of limited resources and unavailability of required features within TEAMEngine the current ETS has different limitations:  ETS (arrangements / namings of tests) -> aligned with older version of ATS  not all ATS Test-Cases covered by ETS Concentrate on test cases to be tested against OPGW (+Cancel) ›Skip GetQuotation  No inclusion of UserManagement (tested with UserManagement Spec)  Testing with „command-line based“ TEAMEngine  No testing of asynchronous operations Currently async operations (using call-backs) not supported - as not supported by current TEAMEngine Therefore Test-case for SubmitResponse (part of the asynchronous operation "submit") not implemented But(!): I already created template which can later be adapted to support asynch testing see next slides ETS – limitations

18. AR meeting Esrin, 26. January 2011 18  create-monitor instruction sets up a monitor, which is a proxy service  monitor will capture a request from a client and forwards it on to another server  a subsequent examine-monitor instruction returns response when monitor receives a message.  This form allows tests to receive results from requests that they submitted asynchronously.  examine-monitor: returns first unread message that has been sent to a monitor  If no messages have been received, the instruction will wait for one Next TEAMEngine: create-Monitor / examine-monitor <ctl:param name=...... --> false false …………… To be defined by WS-Adressing

19. AR meeting Esrin, 26. January 2011 19  “ETS”-directory: CTL scripts, ReadMe2Prepare4Testing.txt, functions,…  “messages”-directory: requests used by TEAMEngine  Sub-directory which includes EUMETSAT requests  Sub-directory which includes the ESA / OPGW 0.9.6 requests  the “responses”-directory includes the response XML docs from tests  Sub-directory “schema_0_9_6”: order xml schema used for validation of requests / responses ETS – TestEnvironment Directory

20. AR meeting Esrin, 26. January 2011 Slide 20  ATS as separate document (Technical Note) delivered by conterra on 25/01/2010, under consortium review  ATS integrated into Order Spec on 24/02/2010  Update ATS 28/06/2010 Deliverables - ATS

21. AR meeting Esrin, 26. January 2011 Slide 21 Executable Test Suite (ETS) for the Ordering Spec delivered by conterra on 28/06/2010 ETS Technical Note delivered by conterra on 28/06/2010 ReadMe2Prepare 4Testing.txt) for using ETS Update ETS for OSEO 0.9.6 on 28.12.2010 Deliverables - ETS

22. AR meeting Esrin, 26. January 2011 Slide 22 Setup Issue Tracker Included Items Reviewed Order Spec with inputs into Issue Tracker Lots of input for Order ICD Provision to RFC and Order SWG setup Communications with OGC Deliverables – Order ICD

23. AR meeting Esrin, 26. January 2011 Slide 23 Meetings (+ preparation): OGC TC Darmstadt Frascati (OGC TC + MTR) Telecons Results - Other