You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
issue #3599 fhir-flow better support non IBM FHIR Server upstream systems (#3600)
* issue #3599 use next links for fhir-flow checkpoints
Signed-off-by: Robin Arnold <[email protected]>
* issue #3599 make fhir-flow optimizations optional
Signed-off-by: Robin Arnold <[email protected]>
* issue #3599 handle null entry.id
Signed-off-by: Robin Arnold <[email protected]>
Copy file name to clipboardexpand all lines: fhir-flow/README.md
+17-15
Original file line number
Diff line number
Diff line change
@@ -92,19 +92,19 @@ java \
92
92
--downstream-tenant tenant2
93
93
```
94
94
95
-
The fhir-flow application periodically writes out CHECKPOINT values to the log file:
95
+
The fhir-flow application periodically writes opaque CHECKPOINT values to the log file:
96
96
97
97
```
98
-
2022-04-19 17:03:11.982 00000001 INFO impl.UpstreamFHIRHistoryReader CHECKPOINT: 26573
98
+
2022-04-19 17:03:11.982 00000001 INFO impl.UpstreamFHIRHistoryReader CHECKPOINT: X2NvdW50PTUxMiZfZXhjbHVkZVRyYW5zYWN0aW9uVGltZW91dFdpbmRvdz10cnVlJl9zb3J0PW5vbmUmX2NoYW5nZUlkTWFya2VyPTEwMjM=
99
99
```
100
100
101
101
When the run duration time is reached, the application waits for any pending work to complete then writes a FINAL CHECKPOINT message:
102
102
103
103
```
104
-
2022-04-19 17:03:12.983 00000001 INFO impl.UpstreamFHIRHistoryReader FINAL CHECKPOINT: 27723
104
+
2022-04-19 17:03:12.983 00000001 INFO impl.UpstreamFHIRHistoryReader FINAL CHECKPOINT: X2NvdW50PTUxMiZfZXhjbHVkZVRyYW5zYWN0aW9uVGltZW91dFdpbmRvdz10cnVlJl9zb3J0PW5vbmUmX2NoYW5nZUlkTWFya2VyPTEwMjM=
105
105
```
106
106
107
-
The (Java `long`) value can be used to resume processing using the `--change-id-marker` parameter:
107
+
The checkpoint value can be used to resume processing using the `--from-checkpoint` parameter:
| --run-duration | The number of seconds to run before terminating |
126
-
| --upstream-properties | A Java properties file containing connection details for the upstream FHIR server |
127
-
| --upstream-tenant | The IBM FHIR Server upstream tenant name |
128
-
| --downstream-properties | A Java properties file containing connection details for the downstream FHIR server |
129
-
| --downstresam-tenant | The IBM FHIR Server downstream tenant name |
130
-
| --change-id-marker| Start processing from this previously reported checkpoint value |
131
-
| --partition-count | The number of parallel partitions to use for writing to the downstream FHIR server |
132
-
| --partition-queue-size | The number of interactions that can be queued into any partition before blocking further fetches. This puts an upper bound on memory consumption when changes can be fetched more quickly than written to the downstream system, which is often the case. |
133
-
| --reader-pool-size | The size of the thread-pool used to support asynchronous reading of upstream resources |
134
-
| --drain-for-seconds | After the run-duration time has elapsed, wait this number of seconds for the downstream partition queues to empty before exiting |
125
+
| --run-duration {seconds} | The number of seconds to run before terminating |
126
+
| --upstream-properties {properties-file} | A Java properties file containing connection details for the upstream FHIR server |
127
+
| --upstream-tenant {tenant-name} | The IBM FHIR Server upstream tenant name |
128
+
| --downstream-properties {properties-file} | A Java properties file containing connection details for the downstream FHIR server |
129
+
| --downstresam-tenant {tenant-name} | The IBM FHIR Server downstream tenant name |
130
+
| --from-checkpoint {checkpoint-value}| Start processing from this previously reported checkpoint value |
131
+
| --partition-count {n} | The number of parallel partitions to use for writing to the downstream FHIR server |
132
+
| --partition-queue-size {n} | The number of interactions that can be queued into any partition before blocking further fetches. This puts an upper bound on memory consumption when changes can be fetched more quickly than written to the downstream system, which is often the case. |
133
+
| --reader-pool-size {n} | The size of the thread-pool used to support asynchronous reading of upstream resources |
134
+
| --drain-for-seconds {seconds} | After the run-duration time has elapsed, wait this number of seconds for the downstream partition queues to empty before exiting |
135
135
| --parse-resource | Parse each resource received from the upstream system. The default mode is to not parse the resource, and treat the payload as an opaque string which is simply passed from upstream to downstream - thus saving a significant amount of CPU and pressure on the GC. |
136
136
| --log-data | When in log-only mode (not writing to an actual downstream system), include the resource payload data when logging each interaction. |
137
+
| --exclude-transaction-window | When upstream is an IBM FHIR, use the `_excludeTransactionTimeoutWindow=true` query parameter when fetching history to avoid potential issues with missing data in high-volume scenarios. |
138
+
| --prefer-return-minimal | Use the `Prefer: return=minimal` header for upstream history requests. The IBM FHIR Server uses this as an optimization to skip inclusion of the resource in the response Bundle. Only meta-data related to the change history is returned, allowing for the resource data to be read separately using a VREAD interaction. Better throughput can be achieved by performing the VREAD interactions in parallel |
0 commit comments