Background
- OO decision
Scope
- Onboarding test
Solution design
- Scoped from Testbed architecture vision Architectural Building Blocks (ABB)
- Solution Building Blocks is designs from ABBs
Solution Building Blocks:
- UI - Web/Portal/Registration
- Orchestration
- AP administration Rest interface
- Access Points
- TB Rest interface
- Virtual TB AP with proxy endpoint
Testbed functionality
Scoped and prioritized:
UI
- Access control by the means of PEPPOL certificate (priority 1)
- Show log of received transactions from a specific sender (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
- CRUD log of received 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)
Rest interface (Orchestration-AP) (priority 1) (Mike-Philip-Erland)
- "Philip AP" (priority 1) (Philip)
- Oxalis (priority 1) (Erland)
Access Points (Philip-Erland)
- "Philip AP" (priority 1) (Philip)
- Oxalis (priority 1) (Erland)
Virtual TB AP with proxy endpoint
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 | ||||||||||||||||||||||||||