Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
This document describes the message format for TermWeb Business Integration Message Adapter (BIMA). BIMA is used for integration of TermWeb with other enterprise systems via a message broker middleware, such as WebSphere MQ, ActiveMQ, RabbitMQ, Apache Kafka.
BIMA uses the Java Message Service (JMS) standard and Kafka Streams.
Introduction
There are two TermWeb operations that causes BIMA to generate messages: initial transfer (export of term database) and update of term data.
When such an operation occurs, BIMA generates one or more messages and publishes them to the message broker's publish/subscribe topics defined in BIMA's configuration file.
Each message consists of several properties and a message body, which is a XML structure. The properties are useful for applications when filtering messages to avoid unnecessary XML parsing from the body.
Installation
Copy the sample configuration file
toView file name BimaAdapter.properties [TERMWEB_HOME]
and edit it as necessaryEdit
[TERMWEB_HOME]/termweb.properties
and add the following lines:Code Block adapter.class.1=com.termweb4.bima.BimaAdapter adapter.config.1=[TERMWEB_HOME]/BimaAdapter.properties
If you’re going to use JMS you may replace
activemq
libraries with another: RabbitMQ, IBM MQ. If you’re going use another MQ implementation copy any message broker specific jar files to[TOMCAT_HOME]/webapps/ROOT/WEB-INF/lib
that BIMA needs to create instances of TopicConnectionFactory and Topic. By default, TermWeb 4 comes with ActiveMQ implementation files, don’t forget to delete to avoid any conflicts:activemq-client-*.jar
Code Block language cpp // And its transitive dependencies org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1.1 org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:1.0.1 org.fusesource.hawtbuf:hawtbuf:1.11
Configuration
Property | Description |
---|---|
Common properties | |
| Enables or disables the message publishing. Set the value to false to disable the messaging. |
| Enables or disables the message publishing only for JMS publisher. Set the value to false to disable the messaging. |
| Enables or disables the message publishing only for Kafka publisher. Set the value to false to disable the messaging. |
| Defines the max message size in bytes for publishing to the initial topic. A value of 0 indicates no max size for the messages. |
JMS properties | |
| Defines the name pattern for the initial export topic. See below for description of the pattern. |
| Defines the name pattern for the section update topic. See below for description of the pattern. |
| Defines the name pattern for the concept update topic. See below for description of the pattern. |
| Defines the name pattern for the term update topic. See below for description of the pattern. |
| Defines the class name for the TopicConnectionFactory. |
| Defines several properties for the TopicConnectionFactory class. The names of the properties depend on the properties available in the class defined by |
| Defines the class name for the Topic used for initial export messages. |
| The name of the method in the Topic (sub)class used for setting the baseTopicName. Normally this is |
| Other properties for the class defined by |
| Defines the class name for the Topic used for section update messages. |
| The name of the method in the Topic (sub)class used for setting the baseTopicName. Normally this is |
| Other properties for the class defined by |
| Defines the class name for the Topic used for concept update messages. |
| The name of the method in the Topic (sub)class used for setting the baseTopicName. Normally this is |
| Other properties for the class defined by |
| Defines the class name for the Topic used for term update messages. |
| The name of the method in the Topic (sub)class used for setting the baseTopicName. Normally this is |
| Other properties for the class defined by |
Kafka properties | |
| A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping – this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form host1:port1,host2:port2,... |
| An id string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging. Default value is |
| Controls how the client uses DNS lookups. If set to |
| Include JMS topic name as Kafka’s record header |
| Default topic name used for initial export messages sent to Kafka. User may change it for every export later. |
| Topic name used for update section messages sent to Kafka |
| Topic name used for update concept messages sent to Kafka |
| Topic name used for update term messages sent to Kafka |
| Protocol used to communicate with brokers. Valid values are: |
Kafka SASL configuration | |
| SASL mechanism used for client connections. This may be any mechanism for which a security provider is available. |
| The fully qualified name of a SASL login callback handler class that implements the AuthenticateCallbackHandler interface. For brokers, login callback handler config must be prefixed with listener prefix and SASL mechanism name in lower-case. For example, |
| The (optional) value in milliseconds for the external authentication provider connection timeout. Currently applies only to |
| The URL for the OAuth/OIDC identity provider. If the URL is HTTP(S)-based, it is the issuer’s token endpoint URL to which requests will be made to login based on the configuration in |
| The (optional) comma-delimited setting for the broker to use to verify that the JWT was issued for one of the expected audiences. The JWT will be inspected for the standard OAuth “aud” claim and if this value is set, the broker will match the value from JWT’s “aud” claim to see if there is an exact match. If there is no match, the broker will reject the JWT and authentication will fail. |
| JAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described here. The format for the value is: |
| The location of the trust store file. For example: |
| The password for the trust store file. If a password is not set, trust store file configured will still be used, but integrity checking is disabled. Trust store password is not supported for PEM format. |
Kafka producer configuration | |
| Default value is An upper bound on the time to report success or failure after a call to |
| The period of time in milliseconds after which we force a refresh of metadata even if we haven’t seen any partition leadership changes to proactively discover any new brokers or partitions. |
| Controls how long the producer will cache metadata for a topic that’s idle. If the elapsed time since a topic was last produced to exceeds the metadata idle duration, then the topic’s metadata is forgotten and the next access to it will force a metadata fetch request. |
| The producer will attempt to batch records together into fewer requests whenever multiple records are being sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt will be made to batch records larger than this size. Note: This setting gives the upper bound of the batch size to be sent. If we have fewer than this many bytes accumulated for this partition, we will ‘linger’ for the |
| The number of acknowledgments the producer requires the leader to have received before considering a request complete. This controls the durability of records that are sent. The following settings are allowed: |
| The producer groups together any records that arrive in between request transmissions into a single batched request. Normally this occurs only under load when records arrive faster than they can be sent out. However, in some circumstances the client may want to reduce the number of requests even under moderate load. Valid Values: |
| The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted. |
| The maximum size of a request in bytes. This setting will limit the number of record batches the producer will send in a single request to avoid sending huge requests. This is also effectively a cap on the maximum uncompressed record batch size. Note that the server has its own cap on the record batch size (after compression if compression is enabled) which may be different from this. |
| The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. |
| The configuration controls how long the |
| The total bytes of memory the producer can use to buffer records waiting to be sent to the server. If records are sent faster than they can be delivered to the server the producer will block for |
| The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios. |
| The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are |
| Setting a value greater than zero will cause the client to resend any record whose send fails with a potentially transient error. Note that this retry is no different than if the client resent the record upon receiving the error. Produce requests will be failed before the number of retries has been exhausted if the timeout configured by |
| Close idle connections after the number of milliseconds specified by this config. |
| When set to |
| The maximum amount of time in milliseconds that a transaction will remain open before the coordinator proactively aborts it. The start of the transaction is set at the time that the first partition is added to it. If this value is larger than the setting in the broker, the request will fail with a error. |
Name pattern
Anchor | ||||
---|---|---|---|---|
|
The name pattern for the different JMS topics is a text string with variables that will be replaced with values depending on the dictionary, section and language that are affected by the update message. The variables are:
<DICTIONARYID>
Is replaced by the oid of the dictionary.
<SECTIONID>
Is replaced by the oid of the section.
<LANGUAGE>
Is replaced by the language iso code. Only applicable for term update messages. (2-letter)
<TAG>
Is replaced by the tag the user can enter when selecting an initial transmission. Thus, only applicable for initial transmission messages.
Example configuration.
Property | Value |
---|---|
jms.topic.init.namePattern |
|
jms.topic.update.section.namePattern |
|
jms.topic.update.concept.namePattern |
|
jms.topic.update.term.namePattern |
|
Adapter administration
When the adapter is installed in TermWeb an BIMA administration panel is available in TermWeb. Log in as administrator and go to the AdminView → System → BIMA. The administration panel opens.
General panel
The general panel allows the adapter to be enabled and disabled. It also allows temporary disable one of the parts JMS or Kafka. Please note that the setting in BimaAdapter.properties
is not affected by this control. After restarting TermWeb the adapter will be enabled or disabled according to the value in the properties file.
Information about current configuration is also displayed here.
Export panel
The export panel allows the administrator to do an initial transfer of all or a part of the term data in a dictionary. The selection of concept, terms and fields are based on regular Export settings used for normal exports.
Select settings and topic
Start by selecting one of the available export settings. If no setting is appropriate for your needs, you can click the “Create export setting” link which opens the Export settings panel and lets you define a new setting. Save the setting and then select the BIMA administration icon again in the AdminView → System and select the newly created setting.
Continue by entering a name of the topic to which the data should be published. Choose type of message broker configured in adapter (JMS or Kafka)
Click on the “Continue” button.
Confirm your selection
Your selected export setting is now displayed in detail with languages, fields and total number of concepts that will be published when using this setting. By moving your mouse pointer over the language and field summary you will see a list of all languages and fields included.
If this is the data you expected, click the “Start export” button to start publishing the messages. Otherwise, click the “Reset” button to go back and select another export setting and/or topic name.
Export progress
The selected concepts are now retrieved from the database, converted to XML segments, and published to the selected topic. For details about the message format, see section Message structure below.
A progress bar indicates how much of the export is completed. The elapsed time and an estimation of the total time is also given.
You can stop the export by pressing the Stop button. Please note that this may cause receiving systems to only get parts of the data intended.
Export summary
When the export is done, or if the export was stopped by the user, a summary is displayed with the total number of concepts published, together with elapsed time.
Message structure
Message properties
The following specific properties are defined in a JMS message or as header in Kafka’s record:
Property | Type | Description | Possible values |
---|---|---|---|
| String | Contains the oid of the dictionary that contains the object described in this message | Any string |
| String | Contains the oid of the section that contains the object described in this message. | Any string |
| String | Contains the new section oid when the section was changed for Concept, otherwise null. | Any string |
| String | Contains the old section oid when the section was changed for Concept, otherwise null. | Any string |
| String | Identifies the type of data entity that is contained in this message. | Is one of:
|
| String | Identifies the type of action that was performed on the data. | Is one of:
|
| String | Identifies the type of transmission. | Is one of:
|
| Boolean | Identifies if the message was generated in a restore operation in TermWeb. |
|
Initial transmission
During an initial transfer (described in Adapter administration above) BIMA will create a message (or several messages if the message is larger than the maximum message size specified in the config file) for each section in the dictionary being exported. The TransmissionType in the message is set to INITIAL. DictionaryId and SectionId are set to their respective values. All other properties are set to null.
The body of the message is an XML structure containing all the concepts being exported from the section, which could be none if the export setting's filter does not include any concept from this section.
Update transmissions
An update transmission occurs when some term data is updated in TermWeb. This is done by either renaming or deleting a section, creation, modification, or deletion of concepts, or by importing a file. BIMA then creates one or more messages and publishes them to the broker.
Section updates
Messages caused by section updates are published to the section update topic(s) defined by jms.topic.update.section.namePattern
or by kafka.topic.update.section
in the config file. All messages have DataType set to SECTION.
If a section is renamed a message is published to the topic with DataAction set to UPDATED. The XML in the body consists only of the dictionary and section. The new name is found in the “name” attribute of the section tag.
If a section is deleted a message with DataAction set to DELETED is published. Only dictionary and section in the XML.
See Example messages for more detailed information.
Term data updates
For every change there will be a message for the entire concept together with a message for each affected term. There is therefore a redundancy in the messages since the data in the term messages also are included in the concept message.
Concept messages are published to the concept topic(s) defined by jms.topic.update.concept.namePattern
or by kafka.topic.update.concept
in the config file. Term update messages are published to the topic(s) defined by jms.topic.update.term.namePattern
or by kafka.topic.update.term
.
The subscribing client applications can thus select the most appropriate data structure.
In the group of messages, the concept message has DataType set to CONCEPT, an appropriate value set for DataAction and the body is the XML for the entire concept. Each term message has DataType set to TERM, a DataAction value as appropriate and the XML structure for the term.
When importing a file there will be a series of messages, just like if every concept was created or modified manually. The messages will be sent to the broker when the import of the file is completed.
Description of term data update transmissions
The messages generated from the different kinds of updates are as follows.
Creation of a new concept
One message for the entire concept, and one message for each term in the concept. All have DataAction set to CREATED.
Deletion of a concept
One message for the entire concept, and one message for each term in the concept. All have DataAction set to DELETED.
Modification of a concept
One message for the entire concept with DataAction set to UPDATED.
For every term that has been created, there is a message with the term data and DataAction set to CREATED.
For every term that has been deleted, there is a message with the term data and DataAction set to DELETED.
If any term field except the term name or language has been modified, there is a message with the term data and DataAction set to UPDATED.
If the term name or language has been changed, the old term is considered to have been deleted and a new one created. Therefore, this will create two messages: one DELETED and one CREATED.
If any field on the concept level has been modified, a message with DataAction UNMODIFIED is generated for every term that has not already generated a message with DataAction UPDATED, CREATED or DELETED. Subscribing systems can then determine if some action needs to be taken with the data.
If the section has been changed, the concept is considered to have been deleted and new one created. The messages for the deletion are published to the old section's topic and the creation messages are published to the new section's topic.
XML structure
The XML structure for the messages is like the structure of a TermWeb XML export file and is described in TermWeb-
View file | ||
---|---|---|
|
Message example:
Code Block | ||
---|---|---|
| ||
<dictionary id=”8” name=”Automotive terms”> <section id=”16” name="Headings"> <concept id="4116633" termno=”430”> <metadata> <createdOn>1999-05-12 03:12:54</createdOn> <createdBy>admin</createdBy> <changedOn>2004-10-04 13:53:27</changedOn> <changedBy>admin</changedBy> </metadata> <field name="Domain">All domains</field> <field name="Origin">Termlex</field> <field name="Term No.">430</field> ... <term> <metadata> <createdOn /> <createdBy /> <changedOn>2004-10-04 13:53:22</changedOn> <changedBy>admin</changedBy> </metadata> <field name="Term">Lubrication, injection pump</field> <field name="Language">en-GB</field> <field name="Region"/> ... </term> <term> ... </term> ... </concept> ... </section> .... </dictionary> |
As previously stated, there are one message containing the entire concept and one for each term affected for every term data update. The XML structure in a update concept message contains exactly one <concept> tag with corresponding content, for initial transfer it may have multiple concepts. For a term message, the body contains exactly one <term> tag with content.
The Status field of the concept level is also included in every term message before the <term> tag (messages which are sent to: to the topic(s) defined by jms.topic.update.term.namePattern
or by kafka.topic.update.term
), by default messages about terms in this topic don’t contain Concept fields, but Status will be present anyway:
Code Block | ||
---|---|---|
| ||
<dictionary id="97qjc" id4="41" name="Sample new"> <section id="97qk5" id4="1318" name="Sample new"> <concept id="98dve" id4="1005635"> <metadata>...</metadata> <field name="Status">Approved</field> <term id="98dvg" id4="2326755">...</term> </concept> </section> </dictionary> |
Kafka integration
Integration for Kafka is using the same message structure. By default, all messages serialized as JSON strings. XML part of message will be stored in records value.
For initial transmission key will be 1-100
, where 1 and 100 sequential position number of first and last element in message.
Numbering starts with 1.
For update transmission key will be S1234
, C1234
or T1234
depending on type of message. S1234
is for Section, C1234
is an id for Concept and T1234
id for Term. In case of Section change for Concept BIMA will create two messages with same key, but different DataAction: DELETED and CREATED.
Example messages
Term deleted from Concept
Concept has three Terms: English, Swedish and German. User deletes German term. Next records will be sent:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qjs | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | UPDATED | |||||
Restore | false | |||||
Body:
|
A message about German Term that it’s been deleted
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/de | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | DELETED | |||||
Restore | false | |||||
Body:
|
A message about English Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
A message about Swedish Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/sv | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
Term added to Concept
User adds new Spanish Term to Concept consisting of two Terms: English and Swedish. Next records will be sent:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qjs | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | UPDATED | |||||
Restore | false | |||||
Body:
|
A message about new Spanish Term that it’s been added
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/es | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | CREATED | |||||
Restore | false | |||||
Body:
|
A message about English Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
A message about Swedish Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
Term change in Concept
User decides to change Spanish Term from unión aleada
to unión aleado
. Concept consists of two Terms: English and Spanish. Next records will be sent:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qjs | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | UPDATED | |||||
Restore | false | |||||
Body:
|
A message about old Spanish Term that it’s been deleted
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/es | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | DELETED | |||||
Restore | false | |||||
Body:
|
A message about new Spanish Term that it’s been created
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/es | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | CREATED | |||||
Restore | false | |||||
Body:
|
A message about English Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
Concept field update
User changes value of one the Concept fields. Concept has two Terms: English and Swedish. Next records will be sent:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qjs | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | UPDATED | |||||
Restore | false | |||||
Body:
|
A message about English Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
A message about Swedish Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/sv | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
Restore of deleted Term
User restores deleted Swedish Term in Concept. Concept consisted only of one English Term. Next records will be sent:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qjs | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | UPDATED | |||||
Restore |
| |||||
Body:
|
A message about Swedish Term restoration
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/sv | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | CREATED | |||||
Restore |
| |||||
Body:
|
A message about English Term that nothing has been changed.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | UNMODIFIED | |||||
Restore | false | |||||
Body:
|
Section change in Concept
User has changed in Concept field Section. Concept consisted of two English and Swedish Terms
Because of the section change TermWeb will create two messages: Concept deleted and Concept created.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qjs | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
NewSectionId | 97qk5 | |||||
DataType | CONCEPT | |||||
DataAction | DELETED | |||||
Restore | false | |||||
Body:
|
A message about Concept moved to new Section:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qk5 | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qk5 | |||||
OldSectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | CREATED | |||||
Restore | false | |||||
Body:
|
Same rule applies to Terms, in total it will be 4 messages, 2 about Term deletion from one Section, 2 messages about Term creation in another section. To shorten documentation, here will be shown only two messages:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
NewSectionId | 97qk5 | |||||
DataType | TERM | |||||
DataAction | DELETED | |||||
Restore | false | |||||
Body:
|
And term moved message to another section:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/term/Dict-97qjc/Cat-97qjs/en | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qk5 | |||||
OldSectionId | 97qjs | |||||
DataType | TERM | |||||
DataAction | CREATED | |||||
Restore | false | |||||
Body:
|
New Section created in Dictionary
Administrator or User with the rights to edit Dictionary creates new Section, TermWeb will produce next record with new Section.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/category/Dict-97qjc/Cat-98lst | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 98lst | |||||
DataType | SECTION | |||||
DataAction | CREATED | |||||
Restore | false | |||||
Body:
|
Section name change in Dictionary
Administrator or User with the rights to edit Dictionary changes Section name, TermWeb will produce next record with new Section name.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/concept/Dict-97qjc/Cat-97qjs | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | SECTION | |||||
DataAction | UPDATED | |||||
Restore | false | |||||
Body:
|
Section deletion from Dictionary
Administrator or User with the rights to edit Dictionary deletes Section, TermWeb will produce next record with deleted Section information.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName | Subsystem/update/category/Dict-97qjc/Cat-98lst | |||||
TransmissionType | UPDATE | |||||
DictionaryId | 97qjc | |||||
SectionId | 98lst | |||||
DataType | SECTION | |||||
DataAction | DELETED | |||||
Restore | false | |||||
Body:
|
Initial export
User launches initial export via Export panel. TermWeb will create message for every Concept and put it in one record until it possible to make record size smaller than limit defined in adapter property adapter.maxMessageSize
.
All messages will be sent to topic specified by the User in export panel. Key represents order number of concept in export data, it consists of two numbers divided by -
start and finish position for this message.
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName |
| |||||
TransmissionType | INITIAL | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | CREATED | |||||
Restore | false | |||||
Body:
|
Next message will be the same structure, only with new order numbers:
Topic: | ||||||
---|---|---|---|---|---|---|
Kafka header | Value | |||||
JmsTopicName |
| |||||
TransmissionType | INITIAL | |||||
DictionaryId | 97qjc | |||||
SectionId | 97qjs | |||||
DataType | CONCEPT | |||||
DataAction | CREATED | |||||
Restore | false | |||||
Body:
|
In one record can’t be multiple <section>
elements.
Etc, until the end of export.
Table of Contents | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|