Page Comparison

...

Scoped and prioritized:

UI (Mike)

• Access control by the means of PEPPOL certificate (priority 1)
• Show log of received transactions from a specific sender (priority 1)
• Produce from the test log a report of test runs (priority 1)
• Choice of Testbed send/recieve AP  (priority 1)
• Activate sending a transaction to specific AP (controled by the access control) (priority 1)
  • Transaction chosen from a list of (positive)Test instances
  • Though a Testbed AP choosen from a list of Testbed active APs
  • To a specific AP (SUT) controlled by the access control

Orchestration (Mike)

• CRUD Test log of received and sended transactions for a specific SUT (priority 1)
• Activate specific (positive) transactions to be send to a specific receiver through a choosen testbed AP (priority 1)
• Set of generic test instances to be used as transactions (priority 1) 
• Orchestration - TB monitor and AP proxy Rest interface (priority 2) 

Rest interface (Orchestration-AP) (priority 1) (Mike-Philip-Erland)

• "Philip AP"    (priority 1) (Philip)
• Oxalis  Oxalis (priority 1) (Erland)

Access Points (Philip-Erland)

• "Philip AP"    (priority 1) (Philip)
• Oxalis  Oxalis (priority 1) (Erland)

Virtual TB AP with proxy endpoint

Stage 1 - Scope

1. Testbed Controller covers listed test cases and operates with a minimum of manual intervention
2. Ability to verify compliance on a technical level in terms of the PEPPOL AS2 profile
3. Ability to verify compliance on a technical level in terms of the PEPPOL AS4 profile
4. Ability to verify compliance on a technical level in terms of the E-SENS AS4 profile
5. Implemented as a web-based application with a self-service user interface. Self-identification based on PEPPOL test certificate based on PKI v3 is foreseen. Not open to everyone.
6. Provide efficient and (best effort) scalable self-service Testbed on-boarding, for connectivity testing (not for Backbone AP integration)
   
7. The main purpose of the Testbed from the viewpoint of the tester: to support developers and operations with manual processes
8. The main purpose of the Testbed from the viewpoint of OpenPEPPOL: to check the maturity and verify the compliance of an onboarding entity
9. The Testbed Controller is controlled (managed, maintained, operated and supported) by OpenPEPPOL operations.
10. The Testbed Controller is being hosted by a 3rd party in a generic setup (provider) and implemented in a way to ensure minimal maintenance activities. SLA is mandatory between 3rd party host and OpenPEPPOL
11. The Testbed should enable the usage of different PEPPOL compliant AP implementations (like Oxalis, ph-as2 ...) as Backbone APs. The same implementation can be available in different versions.
    
12. The Testbed should produce a report with the result of executed test cases and which Backbone AP implementations were tested. It should be possible to assert the authenticity of the report.
13. Testbed Controller implementation strategy should cater for scalability in scope and functionality
14. A bullshit AP (naming (c) Anna-Lis) implementation must be created that sends out crappy documents without validation (for the negative tests)

Out of scope for version 1.0, in scope for a later version

1. BIS document validation and content conformance
2. SMP server onboarding test (SMP client is in scope)
   
3. Local or regional requirements mandated by OpenPEPPOL Authorities.
4. Having a history of reports sent out (in scope for future Implementations)
5. Identify scenarios where a production certificate might make sense
6. Handle specific HTTP header values appropriate (Connection header, special status codes, ....)

Out of scope forever (until management decides different)

1. Hosting of 3rd party Backbone AP implementations on behalf of OpenPEPPOL are not considered as part of the Testbed operation

Stage 1 - Requirements

Stage 1 - Design

Building Block functionality

Building Blocks:

...

TB monitor and AP proxy 

• Logging of transactions performed (priority 2)
• Orchestration - TB monitor and AP proxy Rest interface (priority 2) 

Misc

• Analyze how to deal with negative test cases (priority 1)
• Implement negative test cases (priority 2) (all)
• Test method (priority 1) (Klaus)
• Production site and governance (priority 2) (all)

Plan (Klaus)