Communication between the individual components on both the production side and the Live Server is performed via gRPC or CORBA and HTTP. MongoDB uses the Mongo Wire Protocol. The Production and Live Systems can be secured with a Firewall if the servers are located on different computers. The servers contact the databases over a JDBC interface,

CoreMedia Content Cloud and the commerce systems communicate over REST interfaces. The concrete communication differs slightly based on the selected deployment scenario which are the content-led scenario for HCL Commerce and the commerce-led scenario.

Internal Communication Protocol

The CoreMedia system supports gRPC and CORBA for internal communication. While servers always offer both protocols for clients to connect, clients can be configured to use either gRPC or CORBA. The protocol can be chosen freely on each start of a component. Currently, CORBA is the default protocol. See Section, “Docker Compose Configuration” and Section “Internal Communication Protocol” on how to set the protocol.

Note that Content Servers and the Workflow Server also contain client parts for internal communication, e.g., for publication, replication, etc. Choosing a protocol on a server therefore does make a difference although services offered by the servers to their clients always cover both protocols.

Note

With release 2512.0 of the CoreMedia system, the Workflow Server does not yet offer gRPC services to its clients. Activating gRPC on clients (e.g., Studio Server or command line tools) won't do any harm as long as these are of release 2512.0, too. Future clients, though, will fail to connect to that Workflow Server if gRPC is active on them.

Keep this in mind when operating a mixed-release CoreMedia system setup. In such scenarios (e.g., during upgrades), it is recommended to leave clients in their default protocol mode which is CORBA.

Processing

On the production side of the CoreMedia system, content is created and edited with CoreMedia Studio or custom clients. Once editing of contents is completed, they are approved and published via the CoreMedia Workflow. During the publication process, the content is put online onto the Master Live Server. If available, Replication Live Servers get noticed and reproduce the changes. Then the content is put online by the Replication Live Server. User generated content is produced via Elastic Social and is stored in MongoDB. Editors can use the Studio plugin to moderate this content.

Content from the commerce server is not copied into the CoreMedia system. Instead, references to the content are hold and are resolved when content is delivered.

The CoreMedia CAE in combination with Native Personalization and Elastic Social creates dynamic HTML pages or any other format (XML, PDF, etc.) from the internal and external content and CoreMedia templates.

Headless Server, on the other hand, delivers content from CoreMedia Content Cloud as JSON data via a GraphQL endpoint. This gives you full flexibility in choosing your frontend technology.