Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

  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:

    • UI - Web/Portal/Registration
    • Orchestartion
    • AP administration interface
    • TB AP
    • Virtual TB AP with proxy endpoint
    • System Under Test (SUT)


Plan (Klaus)


293031323334353637383940414243444546474849505152

Draft stage1 design















































































Test method














































































































































































































































































  • No labels