IBM Global Mailbox - Technical overview

The main components of Global Mailbox and the architecture for the components to work together

High availability in Global Mailbox is based on specific availability principles. There are some limitations to the high availability properties of Global Mailbox.

  • High availability
    The high availability mailboxing capability enables you to deploy a B2B platform that can minimize downtime plus offer disaster recovery capabilities.
  • Global Mailbox system principles
    Global Mailbox solution is designed around some specific availability principles for trading partner connections, user actions, and message processing.
  • High availability properties and limitations of Global Mailbox
    High availability of Global Mailbox is limited during some situations, for example when a data center goes down or when one or more nodes in a data center are not operational.
  • Global Mailbox deployment considerations
    When deploying Global Mailbox, you must consider a few items due to various factors such as, limitations of the supported topology and limitations of the components supporting Global Mailbox.

Global Mailbox is a facility for creating a directory of mailboxes with submailboxes and hosting them across multiple data centers. Messages are created by Global Mailbox for applications (on behalf of trading partners, as application users) and stored in mailboxes.

A mailbox is a secure document payload repository. Mailboxes are secure because there is a permission model that controls who can access which mailbox.

By creating a network of multiple data centers that host mailboxes, the mailboxes can be available even if a data center is not operational. Other data centers in the network continue to perform the transactions. Data, including metadata, is replicated between the data centers.

Mailboxes are have the following features:

  • Mailboxes are organized in a hierarchical tree structure.
  • There is a root mailbox at the highest level in the directory structure.
  • Each mailbox can have only one parent.
  • Mailboxes can be created without an owner, until users or groups and permissions are assigned to them.
  • Mailboxes can contain the following items:
    • Messages
    • Other mailboxes
    • Permission information for specific users
  • Mailbox types
    Mailboxes are a point of integration for applications to access the same message.
The following mailbox types are concepts that contribute to the operation between applications:
  • Traditional mailboxes - Sterling B2B Integrator mailboxes that are in one node, or instance of Sterling B2B Integrator.
  • Sterling File Gateway mailboxes are traditional mailboxes with advanced routing and visibility that is enabled by Sterling File Gateway
  • Global Mailbox can be configured in multiple data centers with replication of the data so that messages are stored in multiple data centers and are available even when one data center is offline or has an interruption in communication. Global Mailbox is an optional feature of Sterling B2B Integrator that enables mailboxes that can be distributed across multiple data centers.
  • Messages

    A message consists of a payload and metadata.

    Message metadata includes message name (file name), size of the file (that is the size of the payload), payload type (inline storage or shared file system storage), and depending on the payload type, the payload itself (inline) or a payload reference identifier. The metadata is stored in Cassandra. The payload is an actual business document or file. A message can have only one payload.

    In Global Mailbox, you can configure a threshold for payload size. If the size of the payload is more than the threshold, the payload is stored in a shared file system storage. If the size is less than the threshold size, it is stored inline with the metadata in Cassandra, as a blob.

    Message replication is the replication of both the message metadata and the message payload. Cassandra handles the metadata replication transparently. If the payload of a message is inline, replication of payload is handled by Cassandra. If the payload is not inline, its replication is performed by a replication server.

    Global Mailbox administrators can manage messages from the Mailbox Explorer page. Global Mailbox administrators can delete messages or view all messages that a specific Global Mailbox contains.

  • Virtual roots

    Each user must be assigned a virtual root to access Global Mailbox.

    The virtual root is the first level of the directory path for a user when they are navigating the mailbox navigation pane.

    To support limited visibility into the mailbox hierarchy, mailboxes are visible to the user as a relative path, while administrators see the mailbox in an absolute or full path. This concept is referred to as the virtual root .

    An administrator user always has a virtual root of / (slash). If a standard user is changed to an admin user, that user is assigned a virtual root value of / (slash). No default virtual root is assigned to users. An admin must assign a virtual root before users can access Global Mailbox.

  • Dead Letter mailbox

    A Dead Letter mailbox is a mailbox that contains AS2 messages that might not be routed for some reason. The Dead Letter mailbox is available by default in Global Mailbox under the root mailbox as /DeadLetter. A Dead Letter mailbox cannot be deleted or renamed.

    If you already have a mailbox that is called Dead Letter in your setup, you must delete or rename the mailbox before you upgrade to v6.0.1 or later. Otherwise, the existing Dead Letter mailbox is overwritten with the new Dead Letter mailbox and your existing messages are lost.

    You can create submailboxes under the Dead Letter mailbox. You can also move messages from the Dead Letter mailbox or delete them. While moving messages to a target mailbox, if the target mailbox has an even