One of the most powerful features provided by Fusion Applications is the out-of-the-box configuration of the HTTP Server at Provisioning time. This feature comes in different flavors, enabling the user to select the most appropriate type of configuration for their environment, including setting it up for use with a load balancer or reverse proxy.
The goal of this blog is to complement the information provided in the Fusion Applications Installation Guide providing practical information about how FA configures the HTTP Server out of the box and how these configurations affect the way requests are processed by the HTTP Server in FA. It does not teach or encourage making manual changes to these configurations as it will most certainly break the FA environment; instead we recommend using it to understand how these configurations affect the FA environment and applying this knowledge when planning your configuration and troubleshooting connectivity issues.
Fusion Applications Provisioning allows users to select certain configuration options that directly affect the HTTP Server configuration. They are:
- Web Tier Configuration: Ports
- Web Tier Configuration: Virtual Host Mode
- Load Balancer Configuration
More details about these FA provisioning configuration options are below:
These settings enable you to specify the ports that will be configured as the main listener ports in the HTTP Server.
[caption id="attachment_26833" align="alignnone" width="400"] Figure 1 - FA Provisioning screen for Web Tier configuration[/caption]
The port numbers provided in the Web Tier configuration screen are used by provisioning to set the listen ports in the HTTP Server.
The HTTP Port (non-SSL) goes in httpd.conf as shown below:
[caption id="attachment_26841" align="alignnone" width="549"] Figure 7 - httpd.conf file snippet showing HTTP Port configuration[/caption]
The SSL port goes in ssl.conf:
[caption id="attachment_26842" align="alignnone" width="477"] Figure 8 -ssl.conf file snippet showing HTTPS Port configuration[/caption]
The 2 Listen directives simply tell the HTTP Server to listen on the specified ports. If you have a FA environment, you may use the browser to access the HTTP Server on these ports and you will get the Fusion Middleware welcome page as shown below:
Note that these ports will not actually get used unless you select Name-based virtual hosts. For IP and Port-based virtual hosts they will still be set, but the respective virtual host ports will be the ports used for each HTTP endpoint instead.
This setting allows you to configure the Virtual Hosts on the HTTP Server. Options are:
[caption id="attachment_26835" align="alignnone" width="400"] Figure 2- FA provisioning screen for Web Tier configuration[/caption]
Virtual hosts are used to enable FA to determine the endpoint for which an incoming HTTP request is intended. For example, a request to http://fusionapps.mycompany.com/soa-infra could refer to the SOA server on any of the Fusion Apps domains, so FA uses virtual hosts with different endpoints (with different hostnames, ports or hostname-port combinations) to resolve this potential ambiguity. There are different endpoints for each domain for both external requests (coming from an end user or external application) and internal (coming from FA itself). In R8 on-premise that’s a total of up to 19 endpoints, including a special external endpoint for the Supplier Portal (Procurement):
- CommonDomain internal/external
- BIDomain internal/external
- CRMDomain internal/external
- FinancialDomain internal/external
- HCMDomain internal/external
- ICDomain internal/external
- ProjectsDomain internal/external
- SCMDomain internal/external
- ProcurementDomain internal/external plus Supplier Portal (external)
So internal requests to the soa-infra app in the CRMDomain should go to the http://fa-crm-internal.mycompany.com/soa-infra URL, external requests for HCM should go to http://fa-hcm.mycompany.com/soa-infra and so on. When the HTTP server receives these requests it knows exactly which domain to forward them to, and that is done through the Virtual Host functionality. For more information on the Virtual Host topic please take a look at the Apache server documentation.
After selecting the Virtual Host mode you will be presented with a different screen allowing the user to pick values for each endpoint. These are shown below:
- IP-based: prompts for hostname:port pairs
[caption id="attachment_26836" align="alignnone" width="477"] Figure 3 - FA Provisioning screen for IP-based virtual host configuration[/caption]
- For Port-based, the next screen shows only the port numbers:
[caption id="attachment_26837" align="alignnone" width="475"] Figure 4 - FA Provisioning screen for Port-based virtual host configuration[/caption]
- For name-based, the next screen shows only hostnames:
[caption id="attachment_26838" align="alignnone" width="475"] Figure 5 - FA Provisioning screen for Name-based virtual host configuration[/caption]
FA Provisioning creates one HTTP Server virtual host (VirtualHost directive) for each HTTP endpoint. These virtual hosts are defined in configuration files located in the moduleconf directory of the HTTP Server. There is one file per domain, each with 2 virtual hosts defined (1 external and 1 internal). The only exception is the ProcurementDomain, which has an additional file that defines the Supplier Portal external endpoint.
Even though FA Provisioning creates them as separate files, they are not processed by The HTTP Server separately, they are all “includes” to httpd.conf so all directives in all files are processed as if they were part of the main configuration file httpd.conf.
[caption id="attachment_26844" align="alignnone" width="248"] Figure 9 - Directory listing with the FA HTTP Server conf files[/caption]
The configuration contained in these files varies depending on the Virtual Host mode selected during Provisisoning:
When IP-based or Port-based virtual host mode is selected, each file will contain:
- One Listen directive for each endpoint, matching the port numbers defined in the provisioning screen for each endpoint.
o For Port-based, the Listen directive will contain only the port number
o For IP-based, the Listen directive will contain the hostname:port pair
- One VirtualHost directive for each endpoint, matching the hostname:port pairs defined in the provisioning screen for each endpoint.
o For Port-based, the hostname portion will be a wildcard (*)
[caption id="attachment_26845" align="alignnone" width="406"] Figure 10 - Sample conf file for the CommonDomain and IP-based virtual host[/caption]
[caption id="attachment_26846" align="alignnone" width="642"] Figure 11 - Sample conf file for the CommonDomain and IP-based virtual host – external[/caption]
The Listen directives enables the HTTP Server to listen on the specified IP:port pair. In the case of a Listen directive with only a port number, the HTTP Server will listen on all network interfaces.
Note that the HTTP Server doesn't use hostnames to match requests to Virtual Hosts when using IP-based mode, it uses the IP address associated with that hostname in the machine where the HTTP Server is running (resolved either via DNS or hosts file). So for IP-based Virtual Hosts, if two virtual hosts with different hostnames are specified but both hostnames resolve to the same IP, requests to either hostname could be taken by either VirtualHost and the HTTP Server will actually always use the first one.
Also, if the hostname specified in the Listen directive cannot be resolved or if no network interface is associated with the IP address in the Listen directive, the HTTP Server will not start.
When Name-based virtual host mode is selected, each file will contain:
- One NameVirtualHost directive for each of the two ports defined in the Webtier Configuration screen with wildcard for the IP/hostname e.g, NameVirtualHost *:10601
- One VirtualHost directive for each endpoint, matching the pattern in the NameVirtualHost directive
[caption id="attachment_26847" align="alignnone" width="401"] Figure 12- Sample conf file for the CommonDomain and Name-based virtual host[/caption]
[caption id="attachment_26848" align="alignnone" width="410"] Figure 13- Sample conf file for the CommonDomain and Name-based virtual host - external[/caption]
The NameVirtualHost directives instruct the HTTP Server to direct incoming requests matching the specified pattern to matching Virtual Hosts. The wildcard on the IP/hostname means all network interfaces. In this case more than one VirtualHost directive will match the request, so the HTTP Server will define which VirtualHost to use based on the ServerName directive inside the VirtualHost
Note that the NameVirtualHost directive itself does not cause the HTTP Server to listen on that port or network interface; the Listen directive is the one that does so and FA Provisioning sets both the HHTP and HTTPS ports in the httpd.conf/ssl.conf files respectively as mentioned above.
This screen allows you to define the hostname/port pair for each HTTP endpoint when using a load balancer. This configuration is in addition to the ones mentioned above.
[caption id="attachment_26839" align="alignnone" width="504"] Figure 6 - FA Provisioning screen for Load Balancer configuration[/caption]
The Load Balancer configuration affects the ServerName setting in each VirtualHost.
If the Load Balancer option is selected during FA Provisioning, then the Servername directive in each FA HTTP endpoint/VirtualHost will contain the Load Balancer hostname:port instead of the hostname:port pair defined for the HTTP Server.
In the example below notice the ServerName directive matches the VirtualHost. This is how it’s set by FA Provisioning for IP-based virtual hosts with no Load Balancer:
[caption id="attachment_26849" align="alignnone" width="628"] Figure 14- Sample VirtualHost for external CommonDomain endpoint[/caption]
Compare that to the example below. In this case, the Load Balancer configuration is used and it’s configured to their external load balancer at https://ww.mycompany.com:443
[caption id="attachment_26850" align="alignnone" width="635"] Figure 15- Sample VirtualHost for external CommonDomain endpoint[/caption]
The Servername directive is used to set how the HTTP Server identifies itself and is normally used in redirection URLs, so setting it to the Load Balancer endpoint instead of the HTTP Server endpoint ensures the server generates correct HTTP headers and self-referential URLs.
In the case of Fusion Applications, however, most URLs/links are actually actively managed and generated by FA itself and the settings in the Topology Manager are used to generate absolute links most of the time. In this case the Servername directive itself has no effect on FA URLs/links.
On the other hand the ServerName directive plays an important role with regards to the FA login redirect to OAM, and it’s used by it to identify the correct Host Identifier (Preferred Host) to process the request.
The sections above are specific to FA and don’t cover the HTTP Server provisioned in IDM. This will be covered in a separate blog entry.
Fusion Applications Installation Guide
A-Team Chronicles - Request Flow in Fusion Applications – Part 1 (by Naveen Nahata)
Apache Name-Based Virtual Hosts