The Smile CDR transaction log is responsible for creating a temporary log of incoming and outgoing transactions as they enter and leave the system via external endpoints such as FHIR REST or HL7 v2 endpoints.
The transaction log is intended to be a troubleshooting tool, which can capture extensive details about transactions as they are being processed. It is not intended to be a permanent audit trail (such as the Audit Log), and is often disabled in production because of its potentially high storage requirements.
The transaction log has several storage mechanisms:
Configuration for the Cluster Manager and the Transaction Log modules is stored in the Node Configuration Properties File.
It is possible to store transaction log events directly in the Smile CDR Cluster Manager database schema. This is a convenient option for low-volume systems, especially non-production systems.
This option is not recommended on systems with large transaction volumes, or where significant log retention is needed since the large amount of data being stored by the Transaction Log can impact the operation of other cluster manager functions, and complicates actions such as backups.
The Cluster Manager Transaction Log Storage can be enabled or disabled using the transactionlog.enabled
setting in your configuration file. The following setting enables the Cluster Manager Transaction Log Storage:
module.clustermgr.config.transactionlog.enabled=true
If this setting is enabled, you can also configure settings related to retention and level of detail to store in the log. See Configuration below for more details.
This module stores Transaction Log events in a dedicated database schema separate from the Cluster Manager. Because the Transaction Log tends to be a very high frequency database (i.e. many records are written in quick succession, and old records are purged regularly), it is generally a good idea to use this module and connect it to a dedicated database schema which is not being used for any other purposes.
Any transaction log modules which are active and started will be used to write transaction log events originating on the same node. For example, if you have a FHIR Endpoint module defined as a part of a node configuration, transaction log events will be written by any Transaction Log Persistence modules running on the same node configuration.
This module should be supplied with database connection settings. You can also configure settings related to retention and level of detail to store in the log. See Configuration below for more details.
This module sends transaction logs off to a topic/queue on a remote broker (ActiveMQ/Kafka). No local persistence of the Transaction Log occurs. Events sent to a module of this type cannot be viewed on the Web Admin Console's Runtime Transaction Log page. When multiple steps of a given Transaction Log are sent separately, (such as is the case with MDM or HL7V2 occasionally), the events are tied together with a matching GUID, allowing you to rebuild a full event downstream, as the sum of its parts.
Note that when Kafka is used as a broker, the Transaction Log's GUID is used as the partitioning key.
The following is an example of a message as it would be received by the terminal broker:
{
"payload": {
"initialTimestamp": "2024-08-20T14:00:30.198-04:00",
"type": "FHIR_REQUEST",
"subType": "FHIR_READ",
"outcome": "SUCCESS",
"endpointNodeId": "Master",
"endpointModuleId": "fhir_endpoint",
"processingTime": 0,
"requestId": "YBNnt0RgBMLNfJmF",
"events": [
{
"endpointLocalHost": "127.0.0.1",
"endpointLocalPort": 8000,
"endpointRemoteHost": "127.0.0.1",
"endpointRemotePort": 37490,
"initialTimestamp": "2024-08-20T14:00:30.198-04:00",
"requestUrl": "http://127.0.0.1:8000/Patient/1403",
"requestVerb": "GET",
"type": "ENDPOINT_RECEIVE"
},
{
"body": "{\n \"resourceType\": \"Patient\",\n \"id\": \"1403\",\n \"meta\": {\n \"versionId\": \"1\",\n \"lastUpdated\": \"2024-08-20T13:59:08.692-04:00\",\n \"source\": \"#NX4jAIEtLyvF8Jpf\"\n }\n}",
"bodyType": "FHIR_JSON",
"endpointLocalHost": "127.0.0.1",
"endpointLocalPort": 8000,
"endpointRemoteHost": "127.0.0.1",
"endpointRemotePort": 37490,
"initialTimestamp": "2024-08-20T14:00:30.223-04:00",
"outcome": "SUCCESS",
"type": "ENDPOINT_REPLY",
"responseStatus": 200
}
],
"userModuleId": "local_security",
"userNodeId": "Master",
"userName": "ADMIN",
"userFamilyName": "GenericUser",
"userGivenName": "Admin",
"transactionGuid": "b5b79664-9bc4-441d-b476-81df6afa6262"
}
}
The transaction log stores the following fields for each transaction it receives:
As relevant, a transaction log entry can contain other information, including facts about the endpoint that facilitated the transaction, as well as the initial payload. On the receiving end, these events are:
In terms of replies generated surrounding a transaction, the following fields are recorded:
For more information see the Transaction Log Events API and the Transaction Log Step API.
persist_bodies_in_clustermgr_db – Controls whether payload bodies will be included in the transaction log. The default value is true. If set to false, items such as raw HTTP requests and responses, HL7 v2.x messages, etc., will not be written to the transaction log. Storing payload bodies is helpful for troubleshooting, but has implications in terms of performance (since this potentially means a lot of extra data is saved in the database) and in terms of privacy (since the transaction log is not aware of the meaning of payloads and therefore can not restrict access by subject or other payload properties). This setting is a master setting, and can be further refined using several other options:
persist_endpoint_receive_bodies – Controls whether the request body for incoming requests such as FHIR create operations will be included in the transaction log entries.
persist_endpoint_reply_bodies – Controls whether the response body for incoming requests such as FHIR search operations will be included in the transaction log entries.
truncate_body.bytes – Limits the size of the transaction log entry by limiting the payload size to a certain number of bytes.
retain_transaction_log_days – Controls how many days to keep transaction log entries before deleting them.
By default, the transaction log will store the request and response bodies for transactions flowing through the system.
By default all events will be written to the transaction log. This is useful for troubleshooting, but can quickly make the transaction log very noisy. For this reason, it is often useful to trim certain events out of the log. Note: these transaction bodies may contain PHI, and access should be controlled accordingly.
Events in the Transaction Log can be customized using the Event Whitelist and Event Blacklist properties. If the Event Whitelist property is set, only events matched by the whitelist will be included in the transaction log. If the Event Blacklist is set, any events that are matched by the blacklist will not be processed. Note that the whitelist is processed first, and any events that pass through the whitelist (or all events, if no whitelist is set) are then filtered by the blacklist.
The format of the whitelist/blacklist is a comma separated list of codes, in the format: [Type Code]|[SubType Code]
. See Event Types and SubTypes below for a list of valid event codes. Both the Type Code and SubType Code may be a code from the list of available codes, or the value *
to match all codes.
The following configuration properties are used to control the lists.
event_whitelist – The whitelist.
event_blacklist – The blacklist.
For example, the following settings will cause the transaction log to include ONLY received HL7 v2.x messages, excluding ADT^A28 and ADT^A31 messages.
module.transaction.config.event_whitelist=HL7V2_INBOUND|*
module.transaction.config.event_blacklist=HL7V2_INBOUND|HL7V2_ADT_A28, HL7V2_INBOUND|HL7V2_ADT_A31
An optional Module ID followed by a period (.
) character (i.e. fhir_endpoint.
) can be prepended to Event Types and SubTypes to further filter transaction logs in the Event Whitelist and Event Blacklist.
Example 1: Transaction logs will include ONLY received HL7 v2.x messages for the endpoint_hl7v2_in_1
module, excluding ADT^02 messages.
module.transaction.config.event_whitelist=endpoint_hl7v2_in_1.HL7V2_INBOUND|*
module.transaction.config.event_blacklist=HL7V2_INBOUND|HL7V2_ADT_A02
Example 2: Transaction logs will include ONLY received HL7 v2.x messages that DO NOT come from the endpoint_hl7v2_in_1
module.
module.transaction.config.event_whitelist=HL7V2_INBOUND|*
module.transaction.config.event_blacklist=endpoint_hl7v2_in_1.HL7V2_INBOUND|*
If you are trying to troubleshoot poor performance on a FHIR operation, enabling Performance Tracing with the transaction log as an enabled target can be a helpful way of diagnosing issues.
With this feature enabled, warnings will be added to your transaction log if the system detects certain types of inefficient queries. In addition, if Capture Raw SQL or Equivalent is also enabled, the raw query sent to the database will be included so you can analyze it, look at query plans, etc.
This section lists the event codes for transaction log entries. Every entry in the transaction log will have exactly one type code and one subtype code.
The Type Code can be thought of as the high level category, with the SubType Code being the specific payload type. Note that these codes can have a many-to-many relationship. For example, the HL7V2_ADT_A01
SubType code means that the specific transaction involves an HL7 v2.x ADT^A01 message. This SubType code will be logged with the Type Code of HL7V2_INBOUND
when this type of message is received by Smile CDR, and will be logged with a Type Code of HL7V2_OUTBOUND
when this message is sent by Smile CDR.
CAMEL_PROCESSOR
|
Camel Processor | Indicates transaction log was generated from a Camel Processor |
CDA_EXCHANGE_PLUS
|
CDA Exchange+ | Indicates that a request has been handled by the CDA Exchange+ module. |
CDS_HOOKS_REQUEST
|
CDS Hooks Request | Indicates that a REST client request has been handled by a CDS Hooks Endpoint. |
CONSENT_SERVICE
|
Consent Service | Indicates that a transaction log was generated by a consent service script |
ETL_IMPORTER
|
ETL Importer | Indicates that a row has been processed during an ETL import job. |
FHIR_REQUEST
|
FHIR Request | Indicates that a FHIR client request has been handled by a Smile CDR FHIR Server Endpoint. |
HL7V2_INBOUND
|
HL7 v2.x Inbound | Indicates that an HL7 v2.x message has been received by Smile CDR. |
HL7V2_OUTBOUND
|
HL7 v2.x Outbound | Indicates that an HL7 v2.x message has been sent by Smile CDR. |
JAVASCRIPT_EXECUTION
|
JavaScript Execution | Used as a fallback for when a transaction type code is not provided |
MDM
|
MDM | Indicates that a transaction log was generated by an MDM script |
P2P_BATCH_JOB
|
P2P Batch Job | Indicates that a P2P batch job has been handled by Smile CDR. |
PERSISTENCE_SCRIPT
|
Persistence Script | Indicates that a transaction log was generated by a persistence script |
PRIOR_AUTH_CRD
|
Prior Authorization CRD | Transaction log for Prior Authorization CRD |
SOAP_REQUEST
|
SOAP Request | Indicates that a SOAP client request has been handled by Smile CDR. |
BATCH_
|
Batch Job Analytics($job-analytics ) |
CAMEL_
|
Camel Process |
CDA_
|
CDA Document failed to import |
CDA_
|
CDA Document Imported |
CDS_
|
Prefetch Request |
CDS_
|
Services List |
CDS_
|
Service Request |
CDS_
|
Submit Feedback Request |
DOCREF
|
DOCREF ($docref ) |
DQM_
|
Batch Job Analytics($job-analytics ) |
DQM_
|
Qpp Build($qpp-build ) |
FHIR_
|
Apply Codesystem Delta: Add Codes |
FHIR_
|
Apply Codesystem Delta: Remove Codes |
FHIR_
|
FHIR Binary Access - Read ($binary-access-read ) |
FHIR_
|
FHIR Binary Access - Write ($binary-access-write ) |
FHIR_
|
Code Lookup ($lookup ) |
FHIR_
|
CodeSystem Subsumes ($subsumes ) |
FHIR_
|
CodeSystem Validate Code ($validate-code ) |
FHIR_
|
Generate Document ($document ) |
FHIR_
|
Translate Code ($translate ) |
FHIR_
|
Fetch Conformance (/metadata ) |
FHIR_
|
Create Resource |
FHIR_
|
Delete Resource |
FHIR_
|
Fetch Page |
FHIR_
|
History (Instance) |
FHIR_
|
History (System) |
FHIR_
|
History (Type) |
FHIR_
|
Mark all resources for reindexing |
FHIR_
|
Add to Metadata ($meta-add ) |
FHIR_
|
Delete from Metadata ($meta-delete ) |
FHIR_
|
Fetch Metadata ($meta ) |
FHIR_
|
Add Partition ($fhir-management-add-partition) |
FHIR_
|
Apply ('$apply') |
FHIR_
|
Care Gaps($care-gaps ) |
FHIR_
|
Collect Data($collect-data ) |
FHIR_
|
CQL($cql ) |
FHIR_
|
Data Requirements($data-requirements ) |
FHIR_
|
Delete Expunge Operation ($delete-expunge) |
FHIR_
|
Delete Partition ($fhir-management-delete-partition) |
FHIR_
|
Diff Operation ($diff) |
FHIR_
|
Evaluate($evaluate ) |
FHIR_
|
Evaluate Measure($evaluate-measure ) |
FHIR_
|
Evaluate Measures($evaluate-measures ) |
FHIR_
|
Search Entire Encounter Record ($everything ) |
FHIR_
|
Search Entire Patient Chart ($everything ) |
FHIR_
|
Search Everything Related to Patients ($everything ) |
FHIR_
|
Expunge Operation ($expunge) |
FHIR_
|
Extract ('$extract') |
FHIR_
|
Get Resource Counts Operation ($get-resource-counts) |
FHIR_
|
GraphQL Operation ($graphql ) |
FHIR_
|
FHIR Bulk Import ($import) |
FHIR_
|
Initiate FHIR Bulk Export ($export ) |
FHIR_
|
Search for most recent or last n=number of Observation records ($lastn) |
FHIR_
|
List Partitions ($fhir-management-list-partitions) |
FHIR_
|
LiveBundle ($livebundle ) |
FHIR_
|
LiveBundle Subscription Group Add ($livebundle-group-add ) |
FHIR_
|
LiveBundle Subscription Group Delete ($livebundle-group-delete ) |
FHIR_
|
LiveBundle Watchlist ($livebundle-watchlist ) |
FHIR_
|
LiveBundle Watchlist Add ($livebundle-watchlist-add ) |
FHIR_
|
LiveBundle Watchlist Delete ($livebundle-watchlist-delete ) |
FHIR_
|
LiveBundle Watchlist Subscribers ($livebundle-watchlist-subscribers ) |
FHIR_
|
FHIR Patient Match ($match ) |
FHIR_
|
MDM Match Resource ($mdm-match ) |
FHIR_
|
MDM Clear links($mdm-clear ) |
FHIR_
|
MDM Create Link ($mdm-create-link ) |
FHIR_
|
MDM Duplicate Golden Resources ($mdm-duplicate-golden-resources ) |
FHIR_
|
MDM Link History ($mdm-link-history ) |
FHIR_
|
MDM Merge Golden Resources ($mdm-merge-golden-resources ) |
FHIR_
|
MDM Not Duplicate ($mdm-not-duplicate ) |
FHIR_
|
MDM Query Links ($mdm-query-links ) |
FHIR_
|
MDM Batch Processing($mdm-submit ) |
FHIR_
|
MDM Update Link ($mdm-update-link ) |
FHIR_
|
Member match ($member-match ) |
FHIR_
|
FHIR Resource Merge Operation ($merge ) |
FHIR_
|
Package ('$package') |
FHIR_
|
Poll For Bulk Export Job Status ($export-poll-status ) |
FHIR_
|
Poll For Bulk Import Job Status ($import-poll-status ) |
FHIR_
|
Populate ('$populate') |
FHIR_
|
Prepopulate ('$prepopulate') |
FHIR_
|
Read Partition ($fhir-management-read-partition) |
FHIR_
|
Reindex Operation ($reindex) |
FHIR_
|
Reindex terminology ($reindex-terminology ) |
FHIR_
|
FHIR Resource Replace References Operation ($hapi.fhir.replace-references ) |
FHIR_
|
Snapshot ($snapshot ) |
FHIR_
|
Submit attachment operation ($submit-attachment ) |
FHIR_
|
Submit Data($submit-data ) |
FHIR_
|
Suggest Keywords |
FHIR_
|
Generate IPS Document ($summary ) |
FHIR_
|
Manually Trigger Subscription ($trigger-subscription ) |
FHIR_
|
FHIR Operation (Unclassified) |
FHIR_
|
Update Partition ($fhir-management-update-partition) |
FHIR_
|
Patch Resource |
FHIR_
|
Perform reindexing pass |
FHIR_
|
Process Message ($process-message ) |
FHIR_
|
Read Resource |
FHIR_
|
Search Across All Resource Types |
FHIR_
|
Search for Resources |
FHIR_
|
Transaction |
FHIR_
|
Update Resource |
FHIR_
|
Upload External Terminology Code System |
FHIR_
|
Validate Resource ($validate ) |
FHIR_
|
Expand ValueSet ($expand ) |
FHIR_
|
Invalidate Expansion ($invalidate-expansion) |
FHIR_
|
ValueSet Validate Code ($validate-code ) |
FHIR_
|
VRead Resource |
HFQL_
|
Execute HFQL Request |
HL7V2_
|
ADT^A01 (Admit) |
HL7V2_
|
ADT^A02 (Transfer) |
HL7V2_
|
ADT^A03 (Discharge) |
HL7V2_
|
ADT^A04 (Register) |
HL7V2_
|
ADT^A05 (Pre-Admit) |
HL7V2_
|
ADT^A06 (Convert OP to IP) |
HL7V2_
|
ADT^A07 (Convert IP to OP) |
HL7V2_
|
ADT^A08 (Update Visit) |
HL7V2_
|
ADT_A10 (Patient Arriving Tracking) |
HL7V2_
|
ADT^A11 (Cancel Admit) |
HL7V2_
|
ADT^A12 (Cancel Transfer) |
HL7V2_
|
ADT^A13 (Cancel Discharge) |
HL7V2_
|
ADT^A14 (Pending Admit) |
HL7V2_
|
ADT^A15 (Pending Transfer) |
HL7V2_
|
ADT^A16 (Pending Discharge) |
HL7V2_
|
ADT^A17 (Swap Patients) |
HL7V2_
|
ADT^A21 (Patient begins LOA) |
HL7V2_
|
ADT^A22 (Patient returns from LOA) |
HL7V2_
|
ADT^A24 (Link Patient Information) |
HL7V2_
|
ADT^A25 (Cancel Pending Discharge) |
HL7V2_
|
ADT^A27 (Cancel Pending Admit) |
HL7V2_
|
ADT^A28 (Add Patient) |
HL7V2_
|
ADT^A29 (Delete Person Information) |
HL7V2_
|
ADT^A30 (Merge Person Information) |
HL7V2_
|
ADT^A31 (Update Patient) |
HL7V2_
|
ADT^A34 (Merge Patient Information) |
HL7V2_
|
ADT^A37 (Unlink Patient) |
HL7V2_
|
ADT^A38 (Cancel Pre-Admit) |
HL7V2_
|
ADT^A39 (Merge Person - Patient ID) |
HL7V2_
|
ADT^A40 (Merge Patient) |
HL7V2_
|
ADT^A45 (Move Visit Information - Visit Number) |
HL7V2_
|
ADT^A47 (Change Patient Identifier List) |
HL7V2_
|
ADT^A54 (Change Attending) |
HL7V2_
|
ADT^A60 (Update Allergies) |
HL7V2_
|
ADT^A61 (Change Consulting) |
HL7V2_
|
BAR^P01 (Establish Billing Account) |
HL7V2_
|
BAR^P12 (Update Diagnosis/Procedures) |
HL7V2_
|
DFT^P03 (Post Detailed Financial Transaction) |
HL7V2_
|
MDM^T02 (Original Document Notification and Content) |
HL7V2_
|
MDM^T04 (Document status change notification and content) |
HL7V2_
|
MDM^T08 (Document Edit Notification and Content) |
HL7V2_
|
MDM^T10 (Document Replacement Notification and Content) |
HL7V2_
|
MDM^T11 (Document Cancel Notification) |
HL7V2_
|
OMG^O19 (General Clinical Order Message) |
HL7V2_
|
ORM^O01 (General Clinical Order Message) |
HL7V2_
|
ORU^R01 (Unsolicited Result) |
HL7V2_
|
RAS^O17 (Medication Administration) |
HL7V2_
|
RDE^O01 (Medication Order - Legacy) |
HL7V2_
|
RDE^O11 (Medication Order) |
HL7V2_
|
SIU^S12 (Appointment Scheduling) |
HL7V2_
|
SIU^S13 (Appointment Rescheduling) |
HL7V2_
|
SIU^S14 (Appointment Modification) |
HL7V2_
|
SIU^S15 (Appointment Cancellation) |
HL7V2_
|
SIU^S17 (Appointment Deletion) |
HL7V2_
|
SIU^S26 (Patient Did Not Show Up for Scheduled Appointment) |
HL7V2_
|
Unknown Message Trigger |
HL7V2_
|
VXU^V04 (Unsolicited Vaccination Record Update) |
INVALID_
|
Invalid Request |
OPERATION_
|
CDA Import ($import-cda ) |
P2P_
|
P2P batch job request |
PA_
|
Prior Authorization CRD Routing |
PA_
|
Prior Authorization System Claim Inquire ($inquire ) |
PA_
|
Prior Authorization System Claim Response Submit ($sdh.pa.submit ) |
PA_
|
Prior Authorization System Claim Submit ($submit ) |
UNSPECIFIED
|
Unspecified |
_
|
ValueSet Subsumes (Not Used) |
When ingesting large amounts of data, the transaction log can also be a helpful tool in linking transactions to specific resource storage outcomes.
Note that this feature currently only applies to storage actions performed as a part of FHIR Transaction or Batch operation, since ingestion of large volumes of data is typically performed using these operations.
When Persist Storage Outcome Details is enabled, FHIR Transaction/Batch operations executed through FHIR Endpoint or Camel-based procesing will result in additional details being attached to the corresponsing transaction log entry.
Each write action in the transaction/batch will result in one storage outcome record being attached to the write step within the transaction log entry. For example, if you execute a FHIR Transaction containing 10 POST (create) actions, this will result in 10 Storage Outcome Details being saved.
These outcomes can be viewed within the Web Admin Console, but are more likely to be useful as a part of automated analytics. These records can be fetched using the JSON Admin API Transaction Log Endpoint, pushed using the Transaction Log Broker Module, or accessed directly in the transaction log database.
Each record contains the following columns.
Element | Description |
---|---|
Target Resource Type / Target Resource ID | These columns contain the resource Type and ID for the resource that was ultimately persisted. In the case of a Create With Client Assigned ID, these values will contain the ID that was assigned by the client in the Bundle. In the case of a standard Create, these columns will contain the ID that was assigned by the server. |
Outcome | This column contains the Storage Outcome Code indicating what action was specifically taken for the entry. |
Source Resource Type / Source Resource ID |
These columns will contain the resource Type and ID from the
request Bundle. If the request Bundle contains placeholder IDs,
the original placeholder ID will be stored here. If the Outcome
code is AUTOMATICALLY_CREATED_PLACEHOLDER_RESOURCE ,
these columns will contain the resource Type and ID for the resource
which caused the given placeholder to be created.
|
Transaction logs can be configured to display request body contents when viewed in the admin console.
By default, transaction logs will not display body contents, thereby hiding Personal Health Information (PHI) and Personal Identifiable Information (PII).
This can be turned on for debugging purposes by using:
Transaction logs are stored in Coordinated Universal Time (UTC) in the database. When transaction logs are viewed in the list, the time is displayed as in the server local timezone. And when a transaction log is viewed in a detail view, the time is displayed as in the client local timezone.
Note that if the client timezone is switched to be a different timezone than the server, the time displayed in the transaction log list and in the detail transaction event view might contain some inconsistencies. In this case, clear the cache in your browser will resolve the issue.
You can configure multiple transaction logs to be used by the system. This is useful if you want to have different transaction logs for different purposes or retention periods. For example, you might want to have a transaction log that only logs FHIR transactions, and another transaction log that only logs HL7 v2.x transactions. This could be accomplished by setting up two transaction logs, and setting their allowlist/denylist events to reflect what you are interested in storing.
To setup multiple transaction logs you will need to modify the cdr-config-Master.properties file in Properties mode since due to security reasons this cannot be setup in the Web Admin Console. In the properties file, duplicate the existing Transaction Log parameters and change the module name and the database. Then you can modify whitelist and blacklist properties accordingly. In the following example the transaction log will record all FHIR Request transactions except the binary read & write transactions. See the list of Event Types and SubTypes.
#################################################################
# External Transaction Log DB Config
#################################################################
module.transactionsFHIR.type=TRANSACTION_LOG_PERSISTENCE
module.transactionsFHIR.config.db.driver=H2_EMBEDDED
module.transactionsFHIR.config.db.url=jdbc:h2:file:./database/h2_transactionsFHIR;DB_CLOSE_ON_EXIT=FALSE
<other module settings>
module.transactionsFHIR.config.event_whitelist=FHIR_REQUEST|*
module.transactionsFHIR.config.event_blacklist=FHIR_REQUEST|FHIR_BINARY_ACCESS_READ,FHIR_REQUEST|FHIR_BINARY_ACCESS_WRITE
In this next example, the transaction logs for HL7V2 events will be recorded to the first broker topic, and all other events will be recorded to the second broker topic.
#################################################################
# External Transaction Log DB Config for HL7V2 message transaction logs
#################################################################
module.transaction_broker_hl7.type=TRANSACTION_LOG_BROKER
module.transaction_broker_hl7.config.broker.channel.name=hl7v2-events
module.transaction_broker_hl7.config.persist_bodies_in_clustermgr_db=true
module.transaction_broker_hl7.config.event_whitelist=HL7V2|*
#################################################################
# External Transaction Log DB Config for non-HL7V2 message transaction logs
#################################################################
module.transaction_broker.type=TRANSACTION_LOG_BROKER
module.transaction_broker.config.broker.channel.name=other-events
module.transaction_broker.config.persist_bodies_in_clustermgr_db=false
module.transaction_broker.config.event_blacklist=HL7V2|*