The following sections describe the types of embedded servers. See Usage summary of embedded servers for a quick-reference table of functionality for embedded servers.
When you define HTTP and SMTP delivery exchanges for a community, you can choose to use the global server, which can be shared by any community. Alternatively, you can define a community-specific server on a new port. Typically, the global server is the best choice.
Activator matches inbound messages to delivery exchanges for specific communities by the HTTP path or the email address, so there is no need to create a servers for each community. The exception is HTTPS. Since the server certificate and list of trusted client authentication certificates are associated with particular communities, you must create a community-specific HTTP server to handle incoming HTTPS messages for each community.
You also can use an embedded HTTP server for integration pickup by creating a pickup exchange based on the Web Services API server. For security reasons, this server uses a different port than any of the HTTP servers used for trading.
SSL is supported only for inbound trading with HTTP. It is not supported by the Web Services API server (application side), and it is not supported by the SMTP server (partner trading side).
In general, you should not allow outside connections to the Web Services API embedded server.
These servers use a slightly different model than the HTTP and SMTP servers. They are never tied to a particular community. Furthermore, they can host outbound exchanges for partners in addition to inbound exchanges for communities. An FTP server can be used in either a plain context (FTP) or a secure context (FTPS), but not both.
The FTP and SFTP servers also handle secure connections differently than the embedded HTTP server. Since the embedded HTTP server determines whether a connection must be secure based on the port, you must define separate servers on different ports if you want to allow both clear and secure connections. Embedded FTP servers are not tied to a particular community; its trust of client authentication certificates is tied to the server itself and not to a particular community. When you view the settings for an embedded FTP server, there is a Trusted root certificates tab on the server settings page. This is in contrast with embedded HTTP servers, whose trusted SSL certificates are specified on the Certificates dialog for the associated communities.
SFTP has a slightly different model still. SFTP uses public keys instead of certificates to trust clients, and the public keys are tied to each SFTP user. Thus, you do not see a tab related to trusts when you view the settings for an embedded SFTP server. Nor do you find trusted public keys mixed in with a community’s trusted SSL certificates. Instead, you must go to the community or partner that owns the SFTP user and view the settings for that SFTP user. This is a security feature of the SFTP protocol that ties log‑in accounts to specific trusted keys. A key is not be accepted if it is used by the wrong user account for authentication.
With FTP and SFTP servers, all servers on the trading side share the same pool of user accounts. User accounts for trading are kept separate from user accounts for back-end application exchanges. This is further enforced when you create an FTP or SFTP exchange for an application delivery or pickup; you must define a new server instance on a separate port.
As with the Web Services API server, you should generally not allow outside connections to the SFTP embedded server.
ODETTE FTP servers have a one-to-one relationship with delivery exchanges. For this reason, there is no global embedded ODETTE server. Each time you add an OFTP exchange, you also define a new server instance on a new port. This means OFTP servers cannot be shared by multiple communities.
MLLP embedded servers have a one-to-one relationship with delivery exchanges. For this reason, there is no global embedded MLLP server. Each time you add an MLLP exchange, you also define a new server instance on a new port. This means that MLLP servers cannot be shared by multiple communities.
Transfer CFT embedded servers move messages via PeSIT. See PeSIT for more information.
There are two embedded servers available for running the user interface. The default HTTP embedded server enables users to log on to the UI via HTTP. An HTTPS server is available if you want users to connect to the UI by a more secure method.
These embedded servers, created by Activator, are named CnHttpServer and CnHttpsServer.