Closed prtandrup closed 1 year ago
I've added a blocked label to this, although some of the work can commence. It is just to make aware that database migrations are currently not done in CD, due to the switch to DbUp.Reboot. Reach out to MD (Kristian) to get the latest on this.
Blocked label removed. Migrations are now available again in CD.
For the tester: For AC 1:
For AC2; use Postman: Samples collection \ Charges Web API \ ChargeHistory \ SearchAsync - will require a token from the frontend. The request body is ready for use.
For AC3: Alternative to testing it manually; see this automatic test: SearchAsync_WhenCalled_ReturnsChargeHistoryBasedOnSearchCriteria
in ChargeHistoryQueryServiceTests.cs
which covers this AC.
Tested in U-001 (OK with team due to CD issue) :heavy_check_mark:
AC1 - see prev comment
AC3 (and implicitly AC2):
ChargeA created with the following history: Charge ID in db: 9AC9E7EE-26C1-48CC-B8B1-484048678056
[a] Request with date just before Name A1 was registered: (2022-12-20 07:31:13.8339383)
Request & Reply:
[b] Request with date just after Name A1 was registered: (2022-12-20 07:31:13.8339383)
Request & Reply:
[c] Request with date just after Name B was registered: (2022-12-20 07:31:49.8777157)
Request & Reply:
[d] Request with date just after Name A2 was registered: (2022-12-20 07:32:13.0813230)
Request & Reply:
[e] Request with date just after Name Future was registered: (2022-12-20 07:32:46.5681449)
Request & Reply:
Based on the persistence technology selected in #1841, this story is about implementing the historical data model for charge information and being able to populate it with data from accepted Charge Information events, so it can be queried through Charges Web API.
Decision from #1841: Built a custom solution based on service bus, a history function and custom history table(s).
This is considered our query stack.
Acceptance criteria:
[x] 1 Documentation created/updated in GitHub:
Charge Information History data model to be documented here.
Charge Information History persistence flow to be documented, similar to this.Architecture diagram updated
[x] 2 Given a "charge history" Web API request When inspecting the response The response must as a minimum include the following data:
Period start
Period end
Name
Description
Resolution
Transparent invoicing
VAT classification
Tax
Type
Owner
(Additional data might be needed for coupling it with the charge)
[x] 3 Given a charge has been created with the following periods (simplified to name updates only)
01/01/2022 08:02 AM: ChargeA is created with Name: "Name A0" with effective date: 01/02/2022
01/01/2022 08:15 AM: ChargeA is updated with Name: "Name A1" with effective date: 01/02/2022
03/01/2022 10:00 PM: ChargeA is updated with Name: "Name B" with effective date: 01/04/2022
04/01/2022 09:00 PM: ChargeA is updated with Name: "Name A2" with effective date: 01/02/2022
05/01/2022 05:01 AM: ChargeA is updated with Name: "Name future" with effective date: 01/01/2024
When below requests are made, Then the following response are returned
[a] Request with datetime input: 01/01/2022 08:14 AM the response contains ChargeA with "Name A0" per 01/02/2022
[b] Request with datetime input: 01/01/2022 08:16 AM the response contains ChargeA with "Name A1" per 01/02/2022
[c] Request with datetime input: 03/01/2022 10:01 PM: the response contains ChargeA with "Name A1" per 01/02/2022 ChargeA with "Name B" per 01/04/2022
[d] Request with datetime input: 04/01/2022 09:01 PM: the response contains ChargeA with "Name A2" per 01/02/2022 ChargeA with "Name B" per 01/04/2022
[e] Request with datetime input: 05/01/2022 09:01 PM: the response contains ChargeA with "Name A2" per 01/02/2022 ChargeA with "Name B" per 01/04/2022 ChargeA with "Name future" per 01/01/2024
Task list: