| # Process Communication General ERP Enterprise Serverconsists of several processes with each their own specific task. If a process requires the services of another process, Enterprise Server can start this type of process and send requests. This chapter describes how communication between these processes is set up, both local and remote communication are described. Remote communication refers to communication processes that do not reside on the same host. Remote communication is required in a multi-application server setup. Processes on an application server initiate file server processes on the remote master application server to enable the processes to retrieve the required objects and configuration files. InterProcesCommunication table The ipc_boot process uses the ipc_info table as reference table for the communication. Any process that requires the service of another process will search the service based on the server name in the ipc_info file. The executable specified will be started and communication set up according to the specified protocol. Note The ipc_info table does not indicate if the requested server must be started on the local or a remote system. The requesting process must identify that system. Example ipc_boot file
Server name | Protocol (s/p/d) | Executable server
oracle8 | s | ${BSE}/bin/ora8_srv6.2
informix | s | /usr1/bse/bin/inf_srv6.2
bshell | s | ${BSE}/bin/bshell6.2
fs6.2 | p | ${BSE}/bin/fs6.2
db2v5 db2v5 | d s | db2v5_srv6.2 ${BSE}/bin/db2v5_srv6.2
Server name: Used as identifier by the calling program. Protocol: Identifies the communication protocol Socket (s) Pipes (p) Direct connection (d) Executable server: Identifies the executable to communicate with. The ipc_info file resides in ${BSE}/lib. Direct connections are only allowed for database drivers. A direct connection loads the database driver shared library (UNIX) or DLL (Windows) in the database client binary, e.g. the bshell. This is also known as ‘combo-driver’. Direct connections are limited to one database server. By default, a database driver can handle up to 64 sessions simultaneously. If the number of sessions for a database server exceeds this limit, a second database server is started as a separate process; for that reason, a direct driver entry is always followed by a standalone-entry with the ‘p’ or ‘s’ protocol type (see the previous table). Note To overrule the default number of sessions per database driver, use the bdb_max_sessions driver resource. It is not allowed to specify a path for a direct connection. A shared library/DLL associated with a direct connection is picked up from ${BSE}/shlib. It is required that the product version & PA-number of the client binary (e.g. bshell) exactly matches the product version & PA-number of the (database) shared library/DLL from ${BSE}/shlib. Mixing debug and release builds is not possible. Communication protocols Depending on the hardware configuration, you can choose the following protocols for the communication between the client and the server: Socket protocol You can use the socket protocol for both local and remote communication. All sockets are stream sockets (TCP). Pipes protocol You can only perform communication by means of unnamed pipes with local communication. Two pipes are always required, because pipes are unidirectional. Direct connection This is an specific implementation for shared library-based communication, used for database drivers only. Process Communication Local processes If you must start a server process on the same host, the client process starts an ipc_boot process, which provides the server name that must be started. Ipc_boot searches the ipc_info file ($BSE/lib/ipc_info) for the "server name" and pickup the related transport protocol and path of the executable. The ipc_boot process overwrites itself with the identified executable and the client server communication is arranged, leaving 2 processes in place. Remote processes The relevant ERP Enterprise Server executables, such as bshell, database drivers, and audit server are equipped with an internal network layer. This network layer handles both local and remote communication. The client process requests the network layer to initiate a process. Based on the given parameters, the network layer identifies that a remote process is required. Remote configuration information might be required before the user can start the expected server. For example, if a remote database driver must be started, the remote tabledef ($BSE/lib/tabledef6.2) is first required to identify what type of db-driver the user must start. In that case, the file server must be running on the remote host. To start the file server to retrieve remote files The network layer opens the user’s remote user file $BSE/lib/user/r_<user>, and retrieves from that file the required information to start ipc_boot remotely. By default, you can start the remote ipc_boot by means of rexec. However, you cannot use baanlogin instead. On the remote host, the ipc_boot process retrieves from the ipc_info file ($BSE/lib/ipc_info) the path of the fs executable, as well as the transport protocol. That information overwrites the ipc_boot process with an fs process. The fs is the ERP Enterprise Server internal file server that enables remote file access. The client process can now retrieve the required configuration file from the remote fs server to identify which server name you must start. To start the remote server process The network layer of the client process starts ipc_boot on the remote host by means of rexec or Baanlogin. Next, the network layer informs the ipc_boot process of which server name the user is expected to start. The ipc_boot process searches for the requested service name in the ipc_info file, and extracts the related transport protocol and path of the executable execute if the requested server process overwrites its own process space. After the initiation, the following processes will be running: the client process on the local host and the server process on the remote host. Distributed application servers To distribute load over multiple application servers, ERP Enterprise Server supports the AS and MAS concept, having one Master Application Server and one or more Application Servers. The Installation and Configuration Guide for the Application Server (U8392 US) describes the installation and configuration of the application server. The purpose of the AS/MAS concept is to support an environment of distributed application servers, while limiting the impact on maintenance as much as possible. In principle, only the MAS must be update in case of software updates and application servers automatically retrieve required software components and configuration files from the MAS during runtime. Only a portingset update must be installed on all application servers. An application server has all the required process running locally, such as the bshell, database drivers, printer drivers, and also service processes, such as shared memory manager and shared memory timer. Application and configuration data, such as database configuration information, application objects, and user data is retrieved from the master application server. The application server is aware of the master application server through the BSEREM variable. You set this variable during the installation of the application server and stored in the $BSE/lib/bse_vars file. The BSEREM identifies the MAS host and BSE path. If an ERP Enterprise Server-related process on the application server requires configuration files, objects, or other file types, the network layer of that process first searches for these files in the regular way on the local system. If this file is not found locally, the network layer checks if a BSEREM variable is set, and, if so, uses that variable setting to search for the file on the indicated remote host, the MAS. This requires the fs process to be running on the MAS. If the fs process is not yet running, the application server process starts the process as described in “To start the file server to retrieve remote files,” previously in this chapter. Audit servers In a distributed application server environment, all audit servers must run on the same application server. For information on how to start the audit server, refer to “Remote processes,” previously in this chapter The $BSE/lib/audit_srv file identifies the host to run as the audit server. Remote user file You can use the remote user file to identify required information to connect to a remote host. A remote-user file can have multiple entries, identifying multiple remote ERP Enterprise Server environments. For each entry, the following information fields are available: host: Remote host name. [communication protocol [:port number] !] optional Communication protocol: rexec | baan port number: related port number of chosen protocol as set on the remote host. BSE BSE path of the remote environment. [userid] optional OS account to use for login at the remote host. If not set, the local account is used. password The password related to the previously mentioned or local account, stored in encrypted form. [OS authorization or remote user] yes | no [ERP Enterprise Server authorization of remote user] yes | no The remote-user file information is stored in the Systems (ttaad0550m000) session. If the rexec protocol is selected, the value added in front of the BSE-path is “rexec!” If the BaanLogin protocol is selected, the value added will be “baan!” For example: red baan!/usr3/Baan 3F'L|9)c)Z0Rw4|F>=LW+KtpMG_^T1]3 The default protocol here is also “rexec.” Therefore: blue /usr3/BAAN40 3F'L|9)c)Z0Rw4|F>=LW+KtpMG_^T1]3 is exactly the same as: blue exec!/usr3/BAAN40 3F'L|9)c)Z0Rw4|F>=LW+KtpMG_^T1]3 To use a port number that differs from the default, you must add the port number between the protocol and the exclamation point with a colon as the separator, for example: red baan:8000!/usr3/Baan3F'L|9)c)Z0Rw4|F>=LW+KtpMG_^T1]3 The additional fields protocol and port are not yet supported from the session. Therefore, you must add these files manually to the r_users file, if required. Alternately, you can use the following variables: BAANLOGIN_PROTOCOL=1 BAANLOGIN_PORT=8000 If BAANLOGIN_PROTOCOL is not set or has the value 0, nothing has to change in the generated lines. If this variable is set to 1, the string “baan!” can be generated. If BAANLOGIN_PORT is also set, this variable’s value can be used to indicate the port. |