Add orchestrations #41
Conversation
Orchestrations give visibility on how the data is manipulated. THey show us the responses from the different services that the data is sent to on the openhim console.
Co-authored-by: Drizzentic <[email protected]>
|
@bradsawadye Please resolve the merge conflict |
Adds orchestrations for endpoints for retrieving patients
…to add-orchestrations
WalkthroughThis update enhances the Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (22)
- package.json (1 hunks)
- src/middlewares/mpi-mdm-everything.ts (3 hunks)
- src/middlewares/mpi-mdm-summary.ts (1 hunks)
- src/middlewares/openhim-proxy-interceptor.ts (1 hunks)
- src/middlewares/validation.ts (1 hunks)
- src/openhim/mediatorConfig.json (1 hunks)
- src/routes/handlers/fetchPatient.ts (5 hunks)
- src/routes/handlers/fetchPatientResources.ts (4 hunks)
- src/routes/handlers/fetchPatientSummaries.ts (5 hunks)
- src/routes/handlers/matchPatientAsync.ts (2 hunks)
- src/types/response.ts (1 hunks)
- src/utils/kafkaFhir.ts (11 hunks)
- src/utils/utils.ts (6 hunks)
- tests/unit/fetchPatient.ts (3 hunks)
- tests/unit/fetchPatientResources.ts (2 hunks)
- tests/unit/fetchPatientSummaries.ts (2 hunks)
- tests/unit/kafkaAsyncPatientHandler.ts (3 hunks)
- tests/unit/kafkaFhir.ts (4 hunks)
- tests/unit/matchPatientAsync.ts (1 hunks)
- tests/unit/matchPatientSync.ts (12 hunks)
- tests/unit/middlewares.ts (3 hunks)
- tests/unit/utils.ts (1 hunks)
Files skipped from review due to trivial changes (5)
- package.json
- src/middlewares/openhim-proxy-interceptor.ts
- src/openhim/mediatorConfig.json
- tests/unit/kafkaAsyncPatientHandler.ts
- tests/unit/matchPatientAsync.ts
Additional Context Used
Learnings (1)
src/routes/handlers/fetchPatient.ts (1)
User: bradsawadye PR: jembi/mpi-mediator#45 File: src/routes/index.ts:75-79 Timestamp: 2024-05-14T09:04:31.151Z Learning: The `fetchPatientById` function in `src/routes/handlers/fetchPatient.ts` includes internal error handling and returns a formatted response object, making additional try-catch blocks in the route handler unnecessary.
Additional comments not posted (31)
src/types/response.ts (4)
7-7: Optional headers inResponseinterface enhance flexibility.
10-17: Enhancements toRequestinterface improve its adaptability and usability.
20-24: Introduction ofOrchestrationinterface supports new functionality for orchestration tracking.
29-29: Addition oforchestrationstoOpenHimResponseObjectaligns with enhanced orchestration handling.src/middlewares/mpi-mdm-summary.ts (2)
6-6: Import ofOrchestrationis essential for handling new orchestration features.
9-30: Proper handling of orchestrations infetchAllLinkedPatientSummaryenhances visibility and tracking, aligning with PR objectives.src/middlewares/validation.ts (1)
40-40: Update oftransactionStatusto 'Successful' improves consistency in status messaging across the application.src/routes/handlers/matchPatientAsync.ts (1)
17-62: Handling of orchestrations inmatchAsyncHandlerenhances transparency and tracking of asynchronous operations.src/middlewares/mpi-mdm-everything.ts (2)
4-4: Import ofOrchestrationis essential for handling new orchestration features in the MDM expansion.
Line range hint
14-35: Proper handling of orchestrations infetchAllLinkedPatientResourcesenhances visibility and tracking, aligning with PR objectives.src/routes/handlers/fetchPatientResources.ts (1)
27-45: Handling of orchestrations infetchAllPatientResourcesByRefsenhances visibility and tracking, aligning with PR objectives.src/routes/handlers/fetchPatientSummaries.ts (1)
Line range hint
23-55: Handling of orchestrations infetchAllPatientSummariesByRefsenhances visibility and tracking, aligning with PR objectives.tests/unit/fetchPatientResources.ts (1)
122-125: Tests forfetchAllPatientResourcesByRefseffectively verify the handling and population of orchestrations.tests/unit/fetchPatientSummaries.ts (1)
207-210: LGTM! Consider adding assertions to verify the content of the orchestrations array.Verification successful
The search results indicate that there are indeed assertions checking the content of the
orchestrationsarray in various test files. Specifically, there are assertions verifying thenameandresponse.statusof the orchestrations.
tests/unit/matchPatientSync.tstests/unit/kafkaFhir.tsThese files contain assertions that check the content of the
orchestrationsarray, ensuring that the orchestrations are being recorded and validated correctly.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the content of orchestrations in the tests. # Test: Search for assertions related to orchestrations content. Expect: Assertions checking the content. rg --type typescript $'expect(.+orchestrations\[\d+\].response).to'Length of output: 103
Script:
#!/bin/bash # Description: Verify the content of orchestrations in the tests. # Test: Search for assertions related to orchestrations content. Expect: Assertions checking the content. rg 'expect(.+orchestrations\[\d+\].response).to' --glob '*.ts'Length of output: 64
Script:
#!/bin/bash # Description: Search for references to the orchestrations array in the test files. # Find all references to the orchestrations array in .ts files. rg 'orchestrations' --glob '*.ts'Length of output: 8688
src/routes/handlers/fetchPatient.ts (3)
Line range hint
105-168: LGTM! Ensure that the orchestration objects are correctly populated with request and response details.
Line range hint
171-206: LGTM! Ensure that the orchestration objects are correctly populated with request and response details.
Line range hint
38-90: LGTM! Ensure that the orchestration objects are correctly populated with request and response details.Verification successful
The verification script successfully identified multiple instances where orchestration objects are being populated with response details. This confirms that the orchestration objects are correctly initialized and used within the
fetchPatientByQueryfunction.
orchestrations[0].response.status = mpiResponse.status;orchestrations[0].response.body = JSON.stringify(mpiResponse.body);orchestrations[0].response.timestamp = format(new Date(), "yyyy-MM-dd'T'HH:mm:ss.SSSXXX");orchestrations[0].response.status = fhirResponse.status;orchestrations[0].response.body = JSON.stringify(fhirResponse.body);orchestrations[0].response.timestamp = format(new Date(), "yyyy-MM-dd'T'HH:mm:ss.SSSXXX");orchestrations[1].response.status = mpiResponse.status;orchestrations[1].response.body = JSON.stringify(mpiResponse.body);orchestrations[1].response.timestamp = format(new Date(), "yyyy-MM-dd'T'HH:mm:ss.SSSXXX");These lines indicate that the orchestration objects are being populated with the necessary response details, ensuring proper tracking of requests and responses.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the orchestration objects in the function `fetchPatientByQuery`. # Test: Search for the usage of orchestration objects. Expect: Proper initialization and usage. rg --type typescript $'orchestrations\[\d+\].response' src/routes/handlers/fetchPatient.tsLength of output: 126
Script:
#!/bin/bash # Description: Verify the orchestration objects in the function `fetchPatientByQuery`. # Test: Search for the usage of orchestration objects. Expect: Proper initialization and usage. rg --type ts $'orchestrations\\[\\d+\\].response' src/routes/handlers/fetchPatient.tsLength of output: 748
tests/unit/kafkaFhir.ts (2)
118-121: LGTM! Ensure that the orchestration objects are correctly populated with request and response details in error scenarios.
62-67: LGTM! Consider adding more detailed assertions to verify the specific properties of the orchestration objects.Verification successful
The search results indicate that there are multiple references to orchestrations in the test files, including assertions checking their properties. This confirms that the orchestration handling is being tested adequately.
tests/unit/kafkaFhir.tscontains assertions checking the orchestration names and response statuses.- Other test files also include assertions related to orchestrations, ensuring comprehensive coverage.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the content of orchestrations in the tests. # Test: Search for assertions related to orchestrations content. Expect: Assertions checking the content. rg --type typescript $'expect(.+orchestrations\[\d+\].response).to'Length of output: 103
Script:
#!/bin/bash # Description: Verify the content of orchestrations in the tests. # Test: Search for assertions related to orchestrations content. Expect: Assertions checking the content. rg 'expect(.+orchestrations\[\d+\].response).to' --glob '*.ts'Length of output: 64
Script:
#!/bin/bash # Description: Verify the presence of assertions related to orchestrations in the tests. # Test: Search for any assertions related to orchestrations. Expect: Assertions checking the content. rg 'expect(.+orchestrations\[\d+\]).to' --glob '*.ts'Length of output: 55
Script:
#!/bin/bash # Description: Verify the presence of orchestrations in the tests. # Test: Search for any references to orchestrations in the test files. Expect: References to orchestrations. rg 'orchestrations' --glob '*.ts'Length of output: 8688
src/utils/utils.ts (2)
278-286: LGTM! Ensure that thecreateHandlerResponseObjectfunction correctly includes orchestrations in the response object.
Line range hint
111-125: LGTM! Ensure that thebuildOpenhimResponseObjectfunction correctly handles different content types and includes orchestrations in the response object.src/utils/kafkaFhir.ts (1)
Line range hint
57-186: LGTM! Ensure that the orchestration objects in thesendToFhirAndKafkafunction are correctly populated with request and response details.Verification successful
The verification script confirms that the
orchestrationsarray is being used correctly in thesendToFhirAndKafkafunction. The array is initialized and orchestration objects are being pushed to it as expected.
- The
orchestrationsarray is initialized.- Orchestration objects are added to the
orchestrationsarray using thepushmethod.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the orchestration objects in the `sendToFhirAndKafka` function. # Test: Search for the usage of orchestration objects. Expect: Proper initialization and usage. rg --type typescript $'orchestrations\[\d+\].response' src/utils/kafkaFhir.tsLength of output: 113
Script:
#!/bin/bash # Description: Verify the orchestration objects in the `sendToFhirAndKafka` function. # Test: Search for the usage of orchestration objects. Expect: Proper initialization and usage. rg --type ts $'orchestrations\\[\\d+\\].response' src/utils/kafkaFhir.tsLength of output: 70
Script:
#!/bin/bash # Description: Verify the initialization and usage of the orchestration objects in the `sendToFhirAndKafka` function. # Search for the initialization of the `orchestrations` array. rg --type ts 'orchestrations\s*=\s*\[\]' src/utils/kafkaFhir.ts # Search for the addition of orchestration objects to the `orchestrations` array. rg --type ts 'orchestrations\.push' src/utils/kafkaFhir.tsLength of output: 230
tests/unit/matchPatientSync.ts (5)
8-8: Ensure the new imports are utilized effectively in the tests.Also applies to: 13-13
Line range hint
60-102: The test case checks the orchestration handling inmatchSyncHandler. It's good to see the orchestration array being tested for its length, ensuring that no orchestrations were unintentionally added.Also applies to: 111-111, 118-118, 127-128
Line range hint
133-193: This test case effectively checks the error handling and orchestration recording when the patient creation fails. It's crucial to verify that the orchestration details are correctly populated, including the status and the specific request details.
248-257: The test case for successful patient handling in the FHIR store and Kafka is well-implemented. It checks the orchestration details and ensures that the response status is 'Successful', which aligns with the new status updates across the system.Also applies to: 266-273, 301-301
434-441: This test ensures that the orchestration array is empty when no new orchestrations are added, which is a good practice to confirm the expected behavior of the system under test.Also applies to: 450-450
tests/unit/fetchPatient.ts (2)
140-140: The tests verify that the orchestrations array has exactly two entries, which is expected behavior given the operations performed. This is a good check to ensure that all expected orchestrations are being recorded.Also applies to: 251-251
467-467: This test ensures that three orchestrations are recorded, which likely corresponds to the three network calls made in the test. It's important to verify that each external interaction is being orchestrated as expected.tests/unit/middlewares.ts (1)
259-259: The tests check the 'Successful' status in various middleware functions, aligning with the system-wide update from 'Success' to 'Successful'. It's good to see that the orchestrations are being checked, ensuring that they are being recorded as expected.Also applies to: 360-363, 426-429
tests/unit/utils.ts (1)
578-578: Update to 'Successful' aligns with the PR's objective to standardize status messages.
There was a problem hiding this comment.
Actionable comments posted: 0
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (5)
- tests/cucumber/step-definitions/fhirAccessProxy.ts (3 hunks)
- tests/cucumber/step-definitions/mpiAccessProxy.ts (1 hunks)
- tests/cucumber/step-definitions/patientSubmission.ts (2 hunks)
- tests/cucumber/step-definitions/patientSyncMatching.ts (1 hunks)
- tests/cucumber/step-definitions/validation.ts (1 hunks)
Files skipped from review due to trivial changes (4)
- tests/cucumber/step-definitions/fhirAccessProxy.ts
- tests/cucumber/step-definitions/patientSubmission.ts
- tests/cucumber/step-definitions/patientSyncMatching.ts
- tests/cucumber/step-definitions/validation.ts
Additional comments not posted (2)
tests/cucumber/step-definitions/mpiAccessProxy.ts (2)
73-73: LGTM! The status check for a successful response is correctly aligned with the updated status message conventions.
73-73: LGTM! The status check for an error response is correctly handled.
This adds functionality for recording all the data orchestrations in the mpi mediator. Gives us visibility on the requests to hapi fhir, Jempi and kafka from the mediator
Summary by CodeRabbit
New Features
Bug Fixes
Version Updates
v2.3.0for consistency across configuration files.Tests