API: examine API integration with 3rd party services

pbastia commented 7 months ago

Description:

Services like credits, payments (CAS?), messaging, etc. I'm assuming we'll implement each of these as an internal service, in our service layer @DataVillage ?

Acceptance Criteria:

Given When Then

Development Checklist:

[ ] Checklist item
[ ] Checklist item
[ ] Checklist item
[ ] Meets the DOD

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[ ] User story is included
[ ] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included (if required)
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

·Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

Notes:

Dependencies

Blocked by
Blocking

DataVillage commented 7 months ago

Yes, I think our app components should only be communicating with our API. Our API will then relay requests in the service layer to other services as needed. This way authorization and authentication for 3rd party services stays centralized and all code stays consistent. I understand this adds an extra layer, but I think it's a worthwhile trade off.

patriciarussellCAS commented 6 months ago

Likely relates to our connection with CSNR's e-licensing system. Might need to split this into separate epics/tickets. To discuss with @pbastia when he returns.

mikevespi commented 6 months ago

This card will need to be broken out into separate cards. We have two integrations that we know we'll need, one with CSNR for payment related things, and one with the Offset registry. Next steps for CSNR will be another meeting with them, they had mentioned that we could set a meeting and iron out what work will be needed to get our services talking to eachother. We'll want a reasonable idea of what our needs will be before we have that, but don't leave it to the last minute. For the offset registry, we'll want to explore the public API surface and make sure it meets our needs.

pbastia commented 6 months ago

I think this card's purpose is to layout how to implement integration with external services (patterns, architecture diagrams, ...) A small piece of documentation might be just enoug - and a place to list external services and how to use them? cc @andrea-williams and the EmailService

patrickisaac commented 4 days ago

Refinement Notes:

For email component used by the application, specs for COAM emails provided by Business Area

bcgov / cas-coam