Background
- OO decision
Requirements
VisionĀ (Philip)
Building Blocks:
- UI - Web/Portal/Registration
- Orchestartion
- AP administration interface
- TB AP
- Virtual TB AP with proxy endpoint
- System Under Test (SUT)
GITB and ISA Testbed (Klaus)
Stage 1 - Scope
- Testbed Controller covers listed test cases and operates with a minimum of manual intervention
- Ability to verify compliance on a technical level in terms of the PEPPOL AS2 profile
- Ability to verify compliance on a technical level in terms of the PEPPOL AS4 profile
- Ability to verify compliance on a technical level in terms of the E-SENS AS4 profile
- 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.
- Provide efficient and (best effort) scalable self-service Testbed on-boarding, for connectivity testing (not for Backbone AP integration)
- The main purpose of the Testbed from the viewpoint of the tester: to support developers and operations with manual processes
- The main purpose of the Testbed from the viewpoint of OpenPEPPOL: to check the maturity and verify the compliance of an onboarding entity
- The Testbed Controller is controlled (managed, maintained, operated and supported) by OpenPEPPOL operations.
- 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
- 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.
- 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.
- Testbed Controller implementation strategy should cater for scalability in scope and functionality
- 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
- BIS document validation and content conformance
- SMP server onboarding test (SMP client is in scope)
- Local or regional requirements mandated by OpenPEPPOL Authorities.
- Having a history of reports sent out (in scope for future Implementations)
- Identify scenarios where a production certificate might make sense
- Handle specific HTTP header values appropriate (Connection header, special status codes, ....)
Out of scope forever (until management decides different)
- 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:
- UI - Web/Portal/Registration
- Orchestartion
- AP administration interface
- TB AP
- Virtual TB AP with proxy endpoint
- System Under Test (SUT)
Plan (Klaus)
29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Draft stage1 design | ||||||||||||||||||||||||||
Test method | ||||||||||||||||||||||||||