A default IFS Middleware Server installation, whether clustered or not, will service all types of server calls, for example from interactive users using IFS Enterprise Explorer or IFS Web Client, for report rendering and for integrations. It is possible to use separate middle-tier installations for these three types of calls (Clients, Integration and Reporting) as a means to minimize one type of server call potentially affecting the response time or availability of unrelated functionality. Read more this separation at High Availability and Scalability.
Three types of middle-tier installations are possible, each installed to a separate <ifs_home>, possibly on separate hosts:
A Main Server is always mandatory, but as shown here it can be configured to exclude Integration Services functionality. If Integration Services is excluded from the Main Server, then an Integration Server installation is mandatory. An External Report Formatter can always be installed and configured, regardless of whether Integration Services is installed in a separate server or not.
fnd.ifsHomeId=Main (The value
can be anything, this has to be unique for Main Server and Integration Server).fnd.ifsHomeId=Integration (The
value can be anything, this has to be unique for Main Server and
Integration Server).Note: It is not necessary to import items specified in the Database import and deploy panel in all servers. This is enough to do it only once, in one of servers.
Follow installation instructions here.
To propagate the configuration changes that are cached in Application Server caches it is necessary to connect the Main Server and Integration Server via two JMS Bridges. To do that perform the following steps on both servers:
IFS_HOME and
JMS_HOME. IFS_HOME has to point out your
<ifs_home> directory, while
JMS_HOME the script directory from
the previous step.ifs_fndmws_admin_user and
ifs_fndmws_admin_pwd to specify user name and password for the
Admin Server user you have entered in the
Cluster Member Configuration installation step.ifs_fndmws_admin_url has to point out your
Admin Server using the t3 protocol, e.g.
t3://server:58090.ifs_source_url to point out to the
current server. In a single node installation you can use the t3
protocol and point out directly to your ManagedServer1, e.g.
t3://server:58100. In a clustered environment you can use
the http(s) protocol to point out the HTTP Server (OHS), e.g.
http://server:58080, but it is also possible (and recommended) to
use the t3 protocol even in this case. Instead of a single <server>:<port>
you have to enter a comma separate list of your Managed Server
nodes, e.g. t3://node1:58100,node2:58100.true
with false in call to enebleTunneling() method
in configureSeparatedServer() in the
jms.py file.enableTunneling(_server.strip(), true)enableTunneling(_server.strip(), false)Note: preserve indentation - it is crucial in Python script
ifs_target_url to point out the other server
according the rules above.fnd.ifsHomeId you
have configured previously as value of the property ifs_homeid.
ifs_ifsadmin_pwd.ifs_servers.
<LocationMatch ^/bea_wls_internal/>
SetHandler weblogic-handler
</LocationMatch>
Save changes.Note that you don't need to perform this step on a server you're accessing only via t3 protocol.
You can check the status of the created JMS Bridge by running the jms_status.cmd/sh script. Download the zip file including both versions of the script (Windows and Linux) and modify the variables defined at the beginning of the script to reflect your environment.
Follow the steps given below if you want to separate an existing IFS installation into separate installations as suggested here in this documentation: