BackgroundScope
- OO decision
Requirements
Vision (Philip)
- Onboarding test
- Scoped from Testbed architecture vision Architectural Building Blocks (ABB)
- Solution Building Blocks is designs from ABBs
Solution design
Solution Building Blocks:
- UI - Web/Portal/Registration
- OrchestartionOrchestration
- AP administration Rest interface
- Access Points
- TB
- Rest interface
- 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:
...
Testbed functionality
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)
- 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) (Mike-Philip-Erland)
- "Philip AP" (priority 1)
- Oxalis (priority 1)
Access Points (Philip-Erland)
- "Philip AP" (priority 1) (Philip)
- Oxalis (priority 1) (Erland)
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)
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 |
stage 1 design | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Test method | ||||||||||||||||||||||||||