1. System Administration Guide
  2. About the Siebel Application Interface Architecture

About the Siebel Application Interface Architecture

The following figure shows the detailed architecture of the Siebel Application Interface (AI).

This figure descibes the Siebel Application Interface architecture.

The Siebel Application Interface has following major architectural components:

  • Siebel Management Console (SMC):
    • This component is a set of UI components that help the user to enter and save the configuration details into the Gateway.
    • Helps to configure and manage various components of Siebel such as Enterprise, Siebel Server, Application interface etc.
    • If an enterprise has multiple AI nodes, then one of them is called Root AI node.
    • The SMC from root AI node is used to configure enterprise, Siebel servers and all AI nodes including itself.
  • Config Store or AI Profile Store:
    • This component retrieves and stores the required configuration information from the Gateway.
    • This configuration information is known as an "AI Profile".
    • When AI nodes receives its profile from Gateway (this is called profile push), Config store will store the AI profile name in a properties file known as ApplicationInterface.properties.
    • Whenever AI node is restarted, the config store uses the AI Profile name stored in ApplicationInterface.properties to retrieve the profile from gateway. This called profile pull.
    • Config store also helps in getting the connect string from gateway.
    • This connect string contains the information about the Siebel server to which to connect.
  • Application channels:
    • Application channels are the endpoints that are responsible for:
      • Receiving the requests from clients
      • Processing the requests
      • Sending the requests to Siebel server using connections obtained from connection manager
      • Receiving the response from Siebel server
      • Processing the response
      • Sending the response back to clients
    • There are three application channels in AI. They are:
      • UI Channel: Responsible for serving the UI application requests such as callcenter, ecommunication, eservice, epublicsector etc. To these applications generally the client is a browser (such as Chrome, IE or Firefox)
      • EAI Channel: Responsible for serving the EAI related requests such as SOAP web service requests and classic EAI requests. Here the client may be integration handling programs or SOAP UI etc.
      • REST Channel: Responsible for serving the REST requests. Here the clients may be integration handling programs or REST clients such as Postman.
    • Apart from the three channels described above there are two more channels but they are not part of the AI, they are actually are part of config-agent node that runs in every Siebel server node.
      • Outbound Channel
      • JBS Channel
    • All the application channels read their configuration and connect strings from config store.
    • Application channels connect to Siebel server using the connection objects obtained from connection manager.
    • A connection object connects to the server specified in the connect string.
  • Connection Manager: Connection manager is responsible for managing the life cycle of connection objects. Each connection object is a JDB object (JAVA Data Bean) which can connect to the Siebel server specified in the connect string.
    • AI has following three types of connections to server:
      • Session based connections: Here a JDB connection to the server will be created for a user when the user logs in and the connection will be kept open until user logs out or session times out. Each connection will be identified by a Session ID. These types of requests are used for UI applications.
      • Anonymous connections: Here a JDB connection to the server will be created using a pre-defined user known as "anonymous user". The anonymous user name and password will be specified while creating the AI profile and connection manager gets the anonymous user name and password from config store. These types of connections are used for EAI anonymous requests. Here connections are identified using sequence numbers.
      • User based connections: Here JDB connections to server are created using the user name and password given in the request. After serving the request the connections are not closed, instead they are retained to be re-used for subsequent requests (may or may not be from same client) that have same user name and password. These types of requests are used for REST requests. Here the connections are identified by user name.
    • Connection manager has three components to manage three different types of connections described above.

      • Session connection map: This map stores all the session-based connections to the Siebel server; each connection object is mapped to a session ID.

        When a user accesses an application:
        • The connection manager will request the connect string from config store.
        • Creates JDB connection object which connects to the Siebel server specified in the connect string.
        • Initially this connection logs in to Siebel server using anonymous user name and password obtained from config store.
        • Stores the connection object in the Session connection map with session ID as key.
        • When user gives user name and password, the same connection object will re-login using the user name and password provided by user.
        • This connection object will be used to serve all the requests for that client until user logs off or session expires.
        • Once user logs off or connection expires, the JDB connection object will be removed from the session connection map.
      • Anonymous connection pool: This is a pool of anonymous connections used for EAI SOAP anonymous connections. Whenever an anonymous EAI SOAP request arrives (SOAP request with eai_anon as application and without user name and password):
        • The connection manager looks into this pool for a connection, if this pool has a connection, then it will be used to serve the request. If pool does not have a connection, then a new anonymous connection will be created to serve the request.
        • Once the request is served the connection will be returned to the anonymous pool so that it can be used by other anonymous requests.
        • The number of anonymous connections in the pool will be limited by the anonymous pool size specified in the AI profile.
        • Each anonymous connection will use the anonymous user name and password specified in the AP profile.
      • User connection pool: This is a pool of connections for different users used by REST requests. Whenever a REST request arrives with a valid user name and password:
        • The connection manager will look into the user connection pool for a JDB connection with same user name. If it finds the connection, then the request will be served using this connection and if it doesn't find one, then it will create a new connection to serve the request.
        • Once a request is served, the connection will be returned to the user connection pool so that it can be used for subsequent requests with same user name (may or may not be from same client).
        • Maximum and minimum number of connections in this pool is limited by the Max and Min connections specified in the AP profile.

Siebel Application Interface Functional Steps

When AI is freshly installed and is not configured, it will be in light weight mode. It goes through the following steps in serving the requests. Each of the functional step described below is labelled in red in the above diagram

  1. Administrator logs into Siebel Management Console (SMC) using a browser, enters the AI profile parameters, and submits the profile to Gateway.
  2. Gateway saves the profile entered by the user.
  3. Gateway PUSHES the profile to AI and AI saves the profile in its internal Config store.
  4. User sends an application request to AI (the application may be UI or EAI or REST), and the application channel (UI Channel or EAI Channel or REST Channel) will accept the request.
  5. Application channel will request the config store to give connect string. Applications get various other parameters as and when needed from config store.
  6. Config store sends a request to gateway to provide a connect string (for a given object manager), and gateway will discover the server where the requested object manager is running and provides connect string to AI config store. Config store will return the connect string to application channel.
  7. Application Channel requests the connection manager to provide a JDB connection object and provides the connect string and login details. Connection manger provides the JDB connection object that is connected to the Object manager (OM name defined in the connect string) in Siebel server.
  8. Channels send the user requests to Siebel server using the JDB connection object and serve the client.
  9. If the user request requires execution of a JBS (Java Business Service) or outbound web service, then the object manager will hand over the requests to corresponding channels (JBS or outbound channels) in the config-agent running on the same Siebel sever node.
  10. Outbound channel will forward the request to external web service.