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
Copy file name to clipboardExpand all lines: IoTDBJDBC/README.md
+56-9Lines changed: 56 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,31 +50,78 @@ Raw and normalized messages are handled by separate chains:
50
50
51
51
As with input clients, only handlers whose `@Requires` properties match the runtime configuration are created and injected. Each handler provides an order value from configuration, and the service sorts the injected handlers before processing messages. A handler returns an array of messages. Returning one or more messages passes those messages to the next handler in the chain; returning an empty array stops that branch. This allows the same mechanism to support filters, test processors, and final output handlers.
52
52
53
-
The raw data handler chain can include filters such as:
53
+
The raw data handler chain can include these active filters:
| Filter class | Configuration prefix | What it checks |
56
+
| --- | --- | --- |
57
+
|`RawDataContentTypeMessageFilter`|`messagehandler.filter.rawdata.contenttype.*`| The raw message content type. The configured `type` is compared ignoring case. |
58
+
|`RawDataEndpointMessageFilter`|`messagehandler.filter.rawdata.endpointfilter.*`| A regular expression against the raw message endpoint. `findoutcome=FOUND` keeps matching endpoints; `findoutcome=NOT_FOUND` keeps endpoints that do not match. |
59
+
|`RawDataDeviceModelsMessageFilter`|`messagehandler.filter.rawdata.devicemodelsfilter.*`| The device model display name for the raw message's digital twin instance. It accepts one or more configured `modelnames[...]` entries. |
58
60
59
61
It can also include outputs such as:
60
62
61
63
- text output using `messagehandler.output.rawdata.textoutput.*`
62
64
- HTTP output enabled with `messagehandler.output.rawdata.httpclient.enabled`; the current code reads its order and type from `messagehandler.output.rawdata.httpclient.enabled.order` and `messagehandler.output.rawdata.httpclient.enabled.type`
63
65
- NoSQL output settings under `messagehandler.output.rawdata.nosql.*`; the current code enables this bean with `messagehandler.filter.rawdata.nosql.enabled`
64
66
65
-
The normalized data handler chain can include filters and test processors such as:
67
+
The normalized data handler chain can include these active filters and test processors:
| Filter or processor class | Configuration prefix | What it checks or does |
70
+
| --- | --- | --- |
71
+
|`NormalizedDataContentJsonTypeMessageFilter`|`messagehandler.filter.normalizeddata.contentjsontypefilter.*`| The Oracle JSON type of the normalized `value` payload, using `NormalizedData.getContentJsonType()`. `findoutcome=FOUND` keeps listed JSON types; `findoutcome=NOT_FOUND` keeps messages whose JSON type is not listed. |
72
+
|`NormalizedDataContentPathsMessageFilter`|`messagehandler.filter.normalizeddata.contentpathsfilter.*`| Exact content path membership using configured `matchingcontentpath[...]` entries. It supports optional case-insensitive comparison and `findoutcome=FOUND` or `NOT_FOUND`. |
73
+
|`NormalizedDataDeviceModelsMessageFilter`|`messagehandler.filter.normalizeddata.devicemodelsfilter.*`| The device model display name for the normalized message's digital twin instance. It accepts one or more configured `modelnames[...]` entries. |
74
+
|`NormalizedDataRandomMessageFilter`|`messagehandler.filter.normalizeddata.randomfilter.*`| Test-only random filtering. |
75
+
|`NormalizedDataDuplicatorMessageProcessor`|`messagehandler.processor.normalizeddata.duplicator.*`| Test-only message duplication before later handlers run. |
The usual pattern is to set a handler's `.enabled` property to `true` and provide its `.order` property. Lower order values run earlier. Filters normally sit before outputs, and outputs can either pass the message through to later handlers or terminate that branch by returning no messages.
77
82
83
+
The current plural device-model filters replace the older single-model filter path. `RawDataDeviceModelMessageFilter`, `NormalizedDataDeviceModelMessageFilter`, and `NormalizedDataContentPathRegexpMessageFilter` are still present in the source, but their `@Requires` annotations use `.enabled.IGNORETHISONE`, so the normal `.enabled=true` property will not create those beans. Use the plural `devicemodelsfilter` entries and the exact-match `contentpathsfilter` entries described above.
84
+
85
+
Device-model filters use `DeviceModelMessageFilterCore` and `DeviceModelInstancesCache`. The cache opens a database connection, switches to `iotdatacache.schemaname`, and reads `digital_twin_models` and `digital_twin_instances` to map instance ids, external keys, model ids, and model display names. It keeps in-memory maps of successful lookups and sets of known missing ids so repeated messages for the same instance do not repeatedly query the database.
86
+
87
+
The cache needs these properties:
88
+
89
+
| Property | Required | Purpose |
90
+
| --- | --- | --- |
91
+
|`iotdatacache.schemaname`| Yes | IoT data-cache schema, normally `<IOT Domain Shortid>__iot`. The cache uses this as the current database schema. |
92
+
|`devicemodelinstancescache.preloadexistingmodels`| No, defaults to `true`| Preload all model ids and display names at handler configuration time. |
93
+
|`devicemodelinstancescache.preloadexistinginstances`| No, defaults to `true`| Preload all instance ids, external keys, and model ids at handler configuration time. |
94
+
|`datasources.default.url`| Yes for the current DB connection supplier | JDBC URL used to connect to the IoT database. The sample builds it from `iotdatacache.ociregion` and `iotdatacache.connectionname`. |
95
+
|`oci.dbtoken.scope`| Yes when using the access-token DB connection supplier | Scope used by `DBTokenRetriever` when creating the database access token. |
96
+
|`oci.auth.type`| Yes when using the access-token DB connection supplier | Selects the OCI auth provider. The current values are `InstancePrinciple` or `ConfigFile`. |
97
+
|`oci.auth.config.section`| No, defaults to `DEFAULT`| OCI config profile section when `oci.auth.type=ConfigFile`. |
The `contentype` spelling in that example is deliberate: it is the property name the current constructor reads. The filter uses `findoutcome`; older sample comments that mention `filteronmatches` do not match the current code.
0 commit comments