BKG 2.0, EBL 3.0: SD-2860: Update new eBL Solution Providers

[HenrikHL]

User description

SD-2860: Update new eBL Solution Providers

---

PR Type

Enhancement

---

Description

• Add three new eBL Solution Providers to API specifications

• Update DocuTrade, AEOTrade, and SGTraDex provider codes

• Synchronize provider lists across multiple API versions

• Maintain consistency in BKG 2.0 and EBL 3.0 schemas

---

Diagram Walkthrough

flowchart LR
  A["New Providers:<br/>DOCU, AEOT, SGTD"] --> B["EBL v3.0.3"]
  A --> C["EBL PINT v3.0.0"]
  A --> D["EBL ISS v3.0.3"]
  A --> E["BKG v2.0.4"]
  A --> F["EBL SUR v3.0.3"]
  A --> G["EBL END v3.0.3"]
  B --> H["Updated API Schemas"]
  C --> H
  D --> H
  E --> H
  F --> H
  G --> H

Loading

File Walkthrough

	Relevant files
Enhancement	EBL_v3.0.3.yaml Add new eBL Solution Providers to main schema                        ebl/v3/EBL_v3.0.3.yaml Added three new eBL Solution Provider codes: DOCU (DocuTrade), AEOT (AEOTrade), SGTD (SGTraDex) Updated provider enumeration in 8 different schema component locations Maintains consistency with existing provider list format and documentation +24/-0    EBL_PINT_v3.0.0.yaml Add new providers to PINT API specification                            pint/v3/EBL_PINT_v3.0.0.yaml Added three new eBL Solution Provider codes across 4 schema locations Updated provider enumeration in multiple component definitions Aligns PINT API with main EBL specification updates +21/-0    EBL_ISS_v3.0.3.yaml Add new providers to issuance API schema                                  ebl/v3/issuance/EBL_ISS_v3.0.3.yaml Added three new eBL Solution Provider codes in 3 schema locations Updated provider enumeration for issuance-specific components Maintains consistency with parent EBL v3.0.3 specification +15/-0    BKG_v2.0.4.yaml Add new providers to booking API specification                      bkg/v2/BKG_v2.0.4.yaml Added three new eBL Solution Provider codes in 4 schema locations Updated provider enumeration across booking API components Synchronizes BKG 2.0 with EBL 3.0 provider updates +12/-0    EBL_SUR_v3.0.3.yaml Add new providers to surrender API schema                                ebl/v3/surrender/EBL_SUR_v3.0.3.yaml Added three new eBL Solution Provider codes in 3 schema locations Updated provider enumeration for surrender-specific components Aligns surrender API with main EBL specification +9/-0      EBL_END_v3.0.3.yaml Add new providers to endorsement API schema                            ebl/v3/endorsement/EBL_END_v3.0.3.yaml Added three new eBL Solution Provider codes in 3 schema locations Updated provider enumeration for endorsement-specific components Maintains consistency with parent EBL v3.0.3 specification +9/-0
Configuration changes	styleguide.json Update styleguide configuration                                                    .stoplight/styleguide.json Minor configuration or style guide updates Supporting changes for API specification consistency +1/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #SD-2860 🟢 Add DocuTrade (DOCU), AEOTrade (AEOT), and SGTraDex (SGTD) as possible values for codeListProvider. ⚪ Add DocuTrade (DOCU), AEOTrade (AEOT), and SGTraDex (SGTD) as possible values for sendToPlatform.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Update enum with new provider codes Add the new provider codes (DOCU, AEOT, SGTD) to the enum list in addition to the description to ensure API calls with these codes pass validation. ebl/v3/EBL_v3.0.3.yaml [4674-4677] description: ... - `BLOC` (BlockPeer Technologies) - `DOCU` (DocuTrade) - `AEOT` (AEOTrade) - `SGTD` (SGTraDex) +enum: + ... + - BLOC + - DOCU + - AEOT + - SGTD [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 10 __ Why: The suggestion correctly identifies a critical bug where the PR updates the documentation (description) but fails to update the enum list, which would cause API validation to fail for the new codes, defeating the PR's purpose.	High
High-level	Centralize provider list to avoid duplication To improve maintainability, centralize the duplicated eBL solution provider list into a single reusable schema component. Reference this component using $ref in all relevant API definition files. Examples: ebl/v3/EBL_v3.0.3.yaml [5638-5643] - `KTNE` (KTNET) - `CRED` (Credore) - `BLOC` (BlockPeer Technologies) - `DOCU` (DocuTrade) - `AEOT` (AEOTrade) - `SGTD` (SGTraDex) bkg/v2/BKG_v2.0.4.yaml [4855-4860] - `KTNE` (KTNET) - `CRED` (Credore) - `BLOC` (BlockPeer Technologies) - `DOCU` (DocuTrade) - `AEOT` (AEOTrade) - `SGTD` (SGTraDex) Solution Walkthrough: Before: # In ebl/v3/EBL_v3.0.3.yaml components: schemas: SomeObject: properties: sendToPlatform: type: string description: | ... - `BLOC` (BlockPeer Technologies) # In bkg/v2/BKG_v2.0.4.yaml components: schemas: AnotherObject: properties: sendToPlatform: type: string description: | ... - `BLOC` (BlockPeer Technologies) After: # In a shared definitions file/section components: schemas: SharedPlatformProvider: type: string description: | ... - `BLOC` (BlockPeer Technologies) - `DOCU` (DocuTrade) - `AEOT` (AEOTrade) - `SGTD` (SGTraDex) # In ebl/v3/EBL_v3.0.3.yaml and bkg/v2/BKG_v2.0.4.yaml ... properties: sendToPlatform: $ref: '#/components/schemas/SharedPlatformProvider' Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies a significant maintainability issue with duplicated provider lists across multiple API schemas, and the proposed refactoring using $ref is a standard, high-impact solution.	High
More