KR102335257B1 - B2B transaction supply methods and systems that enable interworking between heterogeneous service data - Google Patents

Abstract

According to the invention, a B2B transaction supply system for an integrated interworking service between heterogeneous service data, comprises: a producer service unit including a database for providing a producer service and corresponding to each producer server; an intermediary service unit including a database for providing an intermediary service and corresponding to each intermediary server; a consumer service unit including a database for providing a consumer service and corresponding to each consumer server; and a system manager service unit for performing an issuance-subscription messaging system using a data communication interface with respect to a standardized protocol generated and transmitted from the producer server, the intermediary server and the consumer server. The protocol is a routing key, and includes a first part representing an activity type, a second part representing a unique ID distinguished for each operator or service, and a third part representing a role distinguisher in a platform. Therefore, heterogeneous service databases can be integrated.

Description

B2B transaction supply methods and systems that enable interworking between heterogeneous service data}

The present invention relates to a method of constructing a B2B (Business-to-Business) transaction supply chain topology based on a publish-subscribe communication model that enables an integrated interworking service between heterogeneous service data and a system comprising the same.

1 shows the configuration of a B2B (Business-to-Business) transaction supply system having one existing integrated database.

Referring to FIG. 1, the existing system stores and integratedly manages data on producers P1 to Pn and consumers C1 to Cn in one independent integrated database, and producer P1, producer P2, consumer C, consumer D, consumer E It is structured in a way that provides services in conjunction with others.

Here, the producer may be a goods supplier, a restaurant, or a laundry, and the consumer may be a goods purchaser or an end consumer. In addition, the service site may be a maintenance repair and operation (MRO) service intermediary site or a regional delivery intermediary site.

As such, in the existing general SaaS (Software as a Service) method, when a single integrated database is configured, transaction data increases and performance deteriorates as the number of SaaS service subscribers increases. In this case, there is a problem that the scope affects the entire data of the entire service account.

Meanwhile, FIG. 2 shows the configuration of a B2B transaction supply service having a separate database for one existing service provider.

Referring to FIG. 2 , in the method of configuring a separate database for each service provider, if there are several customers, it is necessary to separately access several sites, and the customer receiving the service cannot have its own database or it is inconvenient to transfer data separately. there is a ham

That is, in the configuration shown in FIG. 2, the data management structure of FIG. 1 has the same advantages as the data management structure of FIG. 1 under the data management structure of the service provider unit, that is, the advantage is that business transactions are recorded in the same database. Even in a business, if there are multiple business partners, there is a problem in having to separately access multiple sites. In addition, under the data management structure of FIG. 2 , a data ownership problem or a data transfer problem occurs because the customer receiving the service cannot have its own database.

Republic of Korea Patent Publication No. 10-2018-0052289

An object of the present invention is to provide a supply chain cloud service communication method capable of integrating heterogeneous service databases based on a publish-subscribe communication model.

Another object of the present invention is to provide a method for configuring a supply chain cloud topology based on a publish-subscribe communication model that enables an integrated service between heterogeneous service databases.

It also aims to provide a supply chain ecosystem cloud service platform using a standalone database based on the publish-subscribe communication model.

Another object of the present invention is to provide a message delivery method on a supply chain ecosystem cloud service within the same business domain based on a publish-subscribe communication model between independent databases.

According to an aspect of the present invention, a method for supplying a B2B (Business-to-Business) transaction capable of an integrated interworking service between heterogeneous service data on a platform including a producer server, an intermediary server, and a consumer server, (a) providing a service for producers A service section for producers that provides and includes a database corresponding to each producer server, a service section for intermediaries that provides services for mediators and includes a database corresponding to each mediator server, and a service section for consumers that provide services for consumers and correspond to each consumer server. To a service unit for a system administrator performing a publish-subscribe messaging system using a data communication interface by generating a standardized first messaging protocol in response to a request from a server corresponding to any one of the service units for consumers including a database. delivering; (b) reading the received first messaging protocol from the service unit for the system manager, and transmitting it to a corresponding server among the producer server, the intermediary server, and the consumer server; (c) after the server receiving the first messaging protocol analyzes and examines the request of the server that generated the first messaging protocol embedded in the first messaging protocol, standardized second messaging corresponding to the result generating a protocol and transmitting it to the service unit for the system manager; (d) reading the received second messaging protocol from the service unit for the system manager, sending a reply to the server that generated the first messaging protocol embedded in the corresponding second messaging protocol; and (e) establishing a B2B transaction corresponding to the first messaging protocol between the server generating the first messaging protocol and the server generating the second messaging protocol.

Preferably, the protocol is a routing key, comprising: a first part indicating a type of activity; a second part indicating a unique ID distinguished for each operator or service; and a third part indicating a role separator within the platform.

According to another feature of the present invention, a B2B (Business-to-Business) transaction supply system capable of an integrated interworking service between heterogeneous service data provides a service for producers and includes a database corresponding to each producer server. ; an intermediary service unit that provides a service for intermediaries and includes a database corresponding to each intermediary server; a service unit for consumers that provides services for consumers and includes a database corresponding to each consumer server; and a service unit for a system administrator that performs a publish-subscribe messaging system using a data communication interface for a standardized protocol generated and delivered by the producer server, the intermediary server, and the consumer server, wherein the protocol is a routing key, a first part indicating the type of activity; a second part indicating a unique ID distinguished for each operator or service; and a third part representing the role delimiter within the platform, wherein the data communication interface of the service unit for the system administrator includes an asynchronous messaging queue, a service common database and a publish-subscribe messaging system unit.

According to the B2B (Business-to-Business) transaction supply method and system capable of integrated interworking service between heterogeneous service data of the present invention, a supply chain cloud service capable of heterogeneous service database integration based on a publish-subscribe communication model There is an effect that can present a B2B transaction supply method having a communication method.

In addition, according to the B2B transaction supply method and system capable of integrated interworking service between heterogeneous service data of the present invention, a supply chain cloud topology based on a publish-subscribe communication model capable of integrated service between heterogeneous service databases can be configured. there is an effect

In addition, according to the B2B transaction supply method and system capable of integrated interworking service between heterogeneous service data of the present invention, it is possible to provide a supply chain ecosystem cloud service platform using an independent database based on the publish-subscribe communication model, while the independent It has the effect of enabling message delivery on the supply chain ecosystem cloud service within the same business domain based on the publish-subscribe communication model between databases.

1 shows the configuration of a B2B (Business-to-Business) transaction supply system having one existing integrated database.
2 shows the configuration of a B2B transaction supply service having a separate database for one existing service provider.
3 illustrates a B2B transaction supply system based on a publish-subscribe communication model between heterogeneous service databases according to an embodiment of the present invention.
4 shows the basic concept of a routing key according to an embodiment of the present invention.
5 is a conceptual diagram illustrating message standardization of a B2B transaction supply system according to an embodiment of the present invention.
6 shows an exemplary service of the B2B transaction supply system according to the present invention.
7 shows an operation example of the B2B transaction supply system according to the present invention.
Fig. 8 shows an example of the basic transaction protocol of the system of Fig. 7;
9 shows an example of a new service extension of the system of FIG. 7 .

Hereinafter, specific embodiments for carrying out the present invention will be described with reference to the accompanying drawings.

In describing the present invention, terms such as first, second, etc. may be used to describe various components, but the components may not be limited by the terms. The terms are only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component.

When a component is referred to as being connected or connected to another component, it may be directly connected or connected to the other component, but it can be understood that other components may exist in between. .

The terminology used herein is used only to describe specific embodiments, and is not intended to limit the present invention. The singular expression may include the plural expression unless the context clearly dictates otherwise.

In this specification, the terms include or include are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, and includes one or more other features or numbers, It may be understood that the existence or addition of steps, operations, components, parts, or combinations thereof is not precluded in advance.

In addition, shapes and sizes of elements in the drawings may be exaggerated for clearer description.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

3 illustrates a business-to-business (B2B) transaction supply system based on a publish-subscribe communication model between heterogeneous service databases according to an embodiment of the present invention.

Referring to FIG. 3 , the B2B transaction supply system 300 according to an embodiment of the present invention includes a producer service unit 301 , an intermediary service unit 302 , a consumer service unit 303 and a system administrator service unit 304 .

The producer service unit 301 provides a producer service and includes a database, a message queue and an application corresponding to each producer server, and the intermediary service unit 302 provides an intermediary service and corresponds to each intermediary server. It includes a database, a message queue, and an application, and the consumer service unit 303 provides a service for the consumer and includes a database, a message queue, and an application corresponding to each consumer server.

In Figure 3, the producer service unit 301 includes an application (App P1), a database (DB P1), and a message queue (MQ P1) corresponding to the producer P1, the application corresponding to the producer P2 (App P2), It includes a database (DB P2), a message queue (MQ P2), and continues to include an application (App Pn), a database (DB Pn), and a message queue (MQ Pn) corresponding to the producer Pn.

And the intermediary service unit 302 includes an application (App M1) corresponding to the intermediary M1, a database (DB M1), and a message queue (MQ M1), and an application corresponding to the intermediary M2 (App M2), a database ( DB M2), the message queue (MQ M2), and also the corresponding application (App Mo), database (DB Mo), message queue (MQ Mo) up to the intermediary Mo.

And the consumer service unit 303 includes an application (App C1), a database (DB P1), and a message queue (MQ P1) corresponding to the consumer C1, and the application (App C2) corresponding to the consumer C2, the database ( DB C2), the message queue (MQ C2), and also the application (App Cm), database (DB Cm), and message queue (MQ Cm) corresponding to consumer Cm.

The system administrator service unit 304 includes a data communication interface unit 340, and also includes an administrator application (app) and a message queue (MQ A). The data communication interface unit 340 includes an asynchronous messaging queue 341 , a service common database unit 342 , and a publish-subscribe messaging system unit 343 .

The B2B transaction supply system based on the publish-subscribe communication model between heterogeneous service databases of the present invention shown in FIG. 3 is to have an integrated system configuration into one system while retaining each independent database, and each stakeholder has independent data can retain ownership. That is, each service and database are basically independent, and physical data separation is possible, security can be strengthened, and separate independent web services can be deployed.

In addition, in the B2B transaction supply system based on the publish-subscribe communication model between heterogeneous service databases shown in FIG. 3, when a new service (app) function is added, while minimizing the influence of each other, SCM (Supply Chain Management) between different services Interlocking is possible, and additional services for independent services are possible.

On the other hand, this type of B2B transaction supply system has a problem that the system implementation may be complicated, but in the present invention, this problem can be overcome through standardization of protocols and messages, which will be described in more detail below. .

These characteristics of the present invention can be summarized in three ways. First, the present invention implements a business messaging system based on asynchronous messaging, secondly, standardization of protocol, and thirdly, standardization of message. Comparing this to a real post office system, in the present invention, the data communication interface unit 340 functions as a post office system that implements asynchronous messaging-based business messaging functions, and standardizes protocols such as postal code system configuration, and various postal codes. It is a standardization of the message, such as providing a service.

4 shows the basic concept of a routing key according to an embodiment of the present invention.

That is, FIG. 4 shows the basic concept of a routing key that provides standardization of a protocol for the B2B transaction platform service of the present invention.

Referring to FIG. 4 , the basic form of a routing key consists of three parts: (<activity> . <business player> . <role>). The first part, <activity>, indicates the type of activity such as quotation, order, delivery, message, and event, and the second part, <business player>, is an alphanumeric unique ID for each business operator or service, and the third part The part <role> represents role separators in the platform such as producers, consumers (consumers), and intermediaries. In this case, each part may designate a specific ID or may represent the entire ID with *.

Through this, in the present invention, it is possible to flexibly route messages in a trading platform of a domain name-type routing key system such as (<activity> . <business player> . <role>) without hard coding. The order of <activity>, <business player>, and <role> does not mean much, and the order can be changed according to the user's convenience.

Table 1 below shows an example of a routing key according to the present invention.

q.p1.p Producer(p) Quote(q) protocol received by p1 o.p1.p Producer(p) Order(o) protocol received by p1 d.p1.p Delivery (d) protocol received by producer (p) p1 m.p1.p Producer(p) message(m) protocol received by p1 e.p1.p Producer (p) Event (e) protocol that p1 receives s.p1.p Producer(p) system(s) protocol received by p1 q.m1.m Intermediary (m) Quote (q) protocol received by m1 q.c1.c Quote (q) protocol received by consumer (c) c1 *.p1.p All (*) protocols that producer (p) p1 listens to q.*.p Quote (q) protocol received by all (*) producers (p) s.*.* System(s) protocol that everyone (*.*) in the platform receives s.system.* System(s) protocol for common management of standard information within the platform

5 is a conceptual diagram illustrating message standardization of a B2B transaction supply system according to an embodiment of the present invention.

Referring to FIG. 5 , the routing key generated by the producer P1 may include q.p1.p, o.p1.p, d.p1.p, e.p1.p, and the like, and the routing key generated by the consumer C1. may be q.c1.c, o.c1.c, d.c1.c, e.c1.c, or the like. On the other hand, q. p1.p, q.c1.c are standardized messages for quotation, o.p1.p, o.c1.c are standardized messages for orders, d.p1.p, d.c1.c are It is a standardized message for delivery, and e.p1.p, e.c1.c may be a standardized message for an event.

In the example of FIG. 5 , when the producer P1 of the producer service unit 301 sends a routing key of *.ec and a message { "message_id": 401, ~~~~~~~ }, this is an event to all purchases. This is to deliver a message for sending information to the publish-subscribe messaging system unit 343 of the service unit 304 for system administrators.

And, if the producer Pn sends a routing key of q.c3.c and a message { "message_id": 201, ~~~~~~~ }, it sends a message to the point of purchase, which is consumer c3, of replying to the quoted price. to the publish-subscribe messaging system unit 343 of the service unit 304 for administrators.

Also, when consumer C1 sends a message with a routing key of o.p1.p and { "message_id": 101, ~~~~~~~ }, it sends a message requesting an order to the supplier, producer P1, to the system. to the publish-subscribe messaging system unit 343 of the service unit 304 for administrators.

And if the consumer Cm sends the message { "message_id": 201, ~~~~~~~ } with the routing key q. This is to deliver a message requesting a so-called reverse auction to the publish-subscribe messaging system unit 343 of the service unit 304 for system administrators.

6 shows an exemplary service of the B2B transaction supply system according to the present invention.

Referring to FIG. 6 , in the exemplary service of the B2B transaction supply system according to the present invention, a consumer, business A, independently operates an app called “Laundrytopia” using a laundry order cloud service app. And, the producer A is using the smart laundry factory ERP service to provide B2B service with the consumer A. And the producer, company b, is using the smart laundry factory ERP service to provide B2B service with the consumer, company A. In addition, operator B as an intermediary operates a price comparison app called “everything about laundry” using the laundry B2B cloud service app, and the producers a and b participate in this.

Here, producers who run restaurants in other fields, c, d, e, … ., y operators are restaurants in Seoul, and they use ERP service for restaurants for order and income management. Business C, a consumer, provides a service called “Seoul Restaurant,” and business D, a consumer, provides a service called “Seoul Chicken.” It provides food order delivery service by connecting restaurants of ., y. And, the intermediary operator E provides a B2B delivery service for the services of consumers A, C, and D.

Meanwhile, the producer z lab receives orders from dentists and uses the smart lab ERP service for internal business management. Consumers F and G dental use the dental management app service, and are linked with the producer z lab to link orders. In addition, the intermediary company H provides an implant price comparison service and is linking with consumers F and G dentistry.

7 shows an operation example of the B2B transaction supply system according to the present invention. FIG. 8 shows an example of a basic transaction protocol of the system of FIG. 7 , and FIG. 9 shows an example of a new service extension of the system of FIG. 7 .

Referring to FIG. 7 , dentists C1 and C2 each use a separate dental operating ERP system. Labs P1 and P2 also use a separate lab operating ERP system. C1 deals with laboratory P1, C2 deals with both laboratories P1 and P2, and conversely, laboratory P1 deals with dental C1 and C2, and laboratory P2 deals with dental C2.

Here, all of these operators are standardized for SCM (Supply Chain Management) integration and linkage, and the new Qigong price comparison company M1 opens a new Qigong price comparison service, and trades labs P1, P2 and L3 for labs. As a result, we have dental C3 as our trading dentistry.

In this situation, referring to FIG. 8 , a message of a protocol called b.c1.c is generated in the laboratory P2 and transmitted to the data communication interface unit 340 . This is to apply for a B2B transaction from laboratory P2 to dentist C1, a customer. Then, the data communication interface unit 340 transmits the received b.c1.c message of the laboratory P2 to the server of the dental C1.

The dental C1 internally examines the b.c1.c message of the laboratory P2, generates a message of a protocol called b.p2.p, and transmits it to the data communication interface unit 340 . This is to transmit the B2B application result from dental C1 to laboratory P2, a producer. Then, the data communication interface unit 340 transmits this message to the laboratory P2. Through this, a B2B transaction contract is established between laboratory P2 and dentist C1.

Thereafter, the dental C1 generates a message of the protocol b.*.p and transmits it to the data communication interface unit 340 . This is a message from dental C1 to request a quote from all producers. Then, the data communication interface unit 340 transmits the b.*.p message of the received dental C1 to the laboratory P1 and the laboratory P2 to request a quotation. In this regard, the laboratory P1 and the laboratory P2 each create a quotation, generate a message of the protocol b.c1.c to reply the quotation and deliver it to the data communication interface unit 340, the data communication interface unit 340 is It receives this and delivers it to the server of dental C1.

In such a configuration, each laboratory and dentistry can have their own database (DB) and develop services without being dependent on the services of a specific customer. For example, C1 dentistry is dealing with two laboratories P1 and P2 that have formed a business relationship, and if the new laboratory called P3 is a business that complies with the standard protocol, online transactions can be made immediately without extra effort. That is, C1 dentistry can request a quote, which is a basic service action, to all (*.p) laboratories in the system through the routing key b.*.p. C2 dentistry will also be able to trade services under the same conditions.

On the other hand, FIG. 9 shows that in a situation where laboratories and dentists are doing business directly connecting each other as shown in FIG. 7, a dental laboratory order relay service provider named M1 appears and delivers dental orders without directly operating a laboratory based on sales power. It shows an example that is growing.

At this time, M1 relayer can connect orders from dentists in the system according to the present invention, and M1 relayer sells a production service act to all (*.p) laboratories in the system through a routing key called p.*.p You can receive product list and price information sold by each laboratory by requesting product information.

In the topology configuration of the present invention, since the laboratory, dentistry, and relay operator all have their own databases, even if the transaction relationship with a specific operator is terminated, big data for business history management and strategy establishment can be continuously maintained.

As described above, the present invention relates to a business (eg, a business having a characteristic in which a plurality of buyer accounts, a plurality of supplier accounts, and a plurality of participating/intermediary accounts transact for the same service or product with the same requirements and In the SCM (supply chain management) cloud service for buyers and suppliers in the MRO (maintenance, repair and operation) procurement market, printing agencies and print shops, dentists and dental laboratories, local restaurants and delivery service providers, etc. It enables suppliers and consumers to have their own independent databases even when they are not dependent on each other and need to have data that suits their own characteristics.

To this end, the present invention achieved this object by integrating the service database into one system using a standardized protocol while maintaining each independent database with the system configuration shown in FIG. 3, and also asynchronous messaging with the same concept as the post office Based on business messaging system, protocol standardization such as zip code system configuration, and message standardization such as various postal service provision were implemented.

That is, the method for constructing a B2B transaction supply chain topology based on the publish-subscribe communication model according to the present invention standardizes the communication protocol in the asynchronous messaging method of the publish-subscribe model, and the routing key of the publish-subscribe model. ) is defined as a unique identifier and 'postal code' of each person, making it a 'post office system' so that necessary messages can be sent and received through this key. In addition, complexity was eliminated by standardizing messages for each type of transaction desired by each business domain, and the entire SCM system was integrated and operated organically while maintaining their own independent database.

Accordingly, a producer such as a printing house or a restaurant can also have a customer database and a transaction database, and share the production and shipment status with other members by maintaining a connected production process database. For example, a design company or an individual as a buyer, or a delivery company as an intermediary can retain order status/transaction details through a separate database, and independent data management and analysis become possible. Through this, in the present invention, it is possible to configure various supply chain service topologies.

The B2B transaction supply method and system capable of integrated interworking service between heterogeneous service data of the present invention having the above configuration has a supply chain cloud service communication method that enables heterogeneous service database integration based on a publish-subscribe communication model. It is possible to provide a B2B transaction supply method, and also to configure a supply chain cloud topology based on a publish-subscribe communication model that enables integrated services between heterogeneous service databases.

In addition, the B2B transaction supply method and system capable of integrated interworking service between heterogeneous service data of the present invention provides a supply chain ecosystem cloud service platform using an independent database based on a publish-subscribe communication model, and issuance- It has the effect of enabling message delivery on the supply chain ecosystem cloud service within the same business domain based on the subscription communication model.

It should be noted that the above-described embodiment is for illustrative purposes only, and not for its limitation. In addition, those skilled in the art will understand that various embodiments are possible within the scope of the technical idea of the present invention.

Claims (7)

In a B2B (Business-to-Business) transaction supply method that enables an integrated interworking service between heterogeneous service data on a platform including a producer server, an intermediary server, and a consumer server,
(a) A service for producers that provides services for producers and includes a database corresponding to each producer server, a service for brokers that provides services for mediators and includes a database corresponding to each mediator server, and a service for consumers and generating a standardized first messaging protocol in response to a request from a server corresponding to any one of the service units for consumers including a database corresponding to each consumer server, and to configure a publish-subscribe messaging system using a data communication interface. delivering to the service unit for system administrators to perform;
(b) reading the received first messaging protocol from the service unit for the system manager, and transmitting it to a corresponding server among the producer server, the intermediary server, and the consumer server;
(c) after the server receiving the first messaging protocol analyzes and examines the request of the server that generated the first messaging protocol embedded in the first messaging protocol, standardized second messaging corresponding to the result generating a protocol and transmitting it to the service unit for the system manager;
(d) reading the received second messaging protocol from the service unit for the system manager, sending a reply back to a server that generated the first messaging protocol embedded in the corresponding second messaging protocol; and
(e) establishing a B2B transaction corresponding to the first messaging protocol between the server generating the first messaging protocol and the server generating the second messaging protocol;
including,
The protocol is a routing key,
a first part indicating the type of activity;
a second part indicating a unique ID distinguished for each operator or service; and
a third part representing a role separator within the platform;
The protocol includes a standardized message, and may request or accept an event corresponding to the standardized message,
the data communication interface of the service section for the system administrator includes an asynchronous messaging queue, a service common database section and a publish-subscribe messaging system section;
The service unit for the system administrator provides a publish-subscribe messaging service between heterogeneous service databases,
The producer server, the intermediary server, and the consumer server each have their own independent databases,
The routing key is made in the form of (<activity> . <business player> . <role>),
The first part of the routing key, <activity>, indicates the type of activity including quotation, order, delivery, message, and event, and the second part of the routing key, <business player>, is a numeric alphabet for each operator or service. It is an (alphanumeric) type unique ID, and <role>, which is the third part of the routing key, represents role identifiers in the platform including producers, consumers, and intermediaries,
The first part, the second part, and the third part are configured to designate a specific ID or to represent the entire ID with *.
delete delete delete According to claim 1,
In step (a), when generating a standardized first messaging protocol in any one of the producer server, the intermediary server, and the consumer server, one or more destinations are designated to generate a protocol including specific event information, and ,
In step (b), the service unit for the system administrator, the method characterized in that the first messaging protocol is delivered to one or more destination servers specified in the first messaging protocol.
delete In a B2B (Business-to-Business) transaction supply system capable of integrated interworking service between heterogeneous service data,
a producer service unit that provides a service for producers and includes a database corresponding to each producer server;
an intermediary service unit providing a service for intermediaries and including a database corresponding to each intermediary server;
a service unit for consumers that provides services for consumers and includes a database corresponding to each consumer server; and
a service unit for system administrators performing a publish-subscribe messaging system using a data communication interface for a standardized protocol generated and transmitted by the producer server, the intermediary server, and the consumer server;
including,
The protocol is a routing key,
a first part indicating the type of activity;
a second part indicating a unique ID distinguished for each operator or service; and
a third part representing a role separator within the platform;
the data communication interface of the service section for the system administrator includes an asynchronous messaging queue, a service common database and a publish-subscribe messaging system section;
The protocol includes a standardized message, and may request or accept an event corresponding to the standardized message,
The service unit for the system administrator provides a publish-subscribe messaging service between heterogeneous service databases,
The producer server, the intermediary server, and the consumer server each have their own independent databases,
The routing key is made in the form of (<activity> . <business player> . <role>),
The first part of the routing key, <activity>, indicates the type of activity including quotation, order, delivery, message, and event, and the second part of the routing key, <business player>, is a numeric alphabet for each operator or service. It is an (alphanumeric) type unique ID, and <role>, which is the third part of the routing key, represents role identifiers in the platform including producers, consumers, and intermediaries,
The first part, the second part, and the third part are configured to designate a specific ID or to represent the entire ID with *.

Images