Orchestra Business Intelligence is typically deployed on the same application server as the main Orchestra application. However, due to performance and scalability reasons it is also possible to deploy Business Intelligence on a separate server. This section provides installation and setup instructions to accomplish this.

Two IP addresses, on the same LAN subnet.

 

The default option from Orchestra 5.4 and later is to use Orchestra Single sign-on authentication and authorization. That means that you only need to log in to Orchestra in order to access the Orchestra Business Intelligence application from the Home page of Orchestra.

Alternatively, it is possible to modify the Orchestra Business Intelligence installation and use the Business Intelligence application's native login page instead of the Orchestra one. This is, however, not recommended.

In order to share the user session token across different servers, the main Orchestra server and the Business Intelligence server must appear to originate from the same domain from the user browser's point of view, otherwise the cookie same-origin policy of web browsers will prohibit sharing of required session information. There are two supported ways to configure this: same-domain or reverse-proxy. These are explained below.

If each server is mapped to a sub-domain of a common parent domain name, the cookie same-origin policy is not violated and session information can be shared. For same-domain policy installs, each IP must be mapped to a sub-domain of your main domain name in the DNS server your users use to connect to Orchestra.

Another option is use a reverse-proxy / load balancer in front of both servers that has the capability to route requests to different back-ends depending on the context path of the request. In this scenario, the user browser only sees proxy.yourdomain.com and thus the same-origin policy is not violated. Session info is safely shared.

Detailed instruction regarding each approach is present further down.

When installing the main Orchestra Server, take the following bullet into consideration:

For the server where the database is run, please take the following bullet into consideration:

 

Make sure you replace the URL in the example above with the URL that matches your environment.

IMPORTANT: If you are planning to use the reverse-proxy strategy for sharing session information across hosts, please specify the path to the proxy-server as URL in the queries above, e.g:

 

You may need to modify the SQL above slightly to be compliant with your particular database vendor (e.g. add schema prefixing on table names or similar). Also, some databases may require the use of true or false instead of 1 or 0 for boolean values such as 'is_distributed' or 'enabled'.

Stat Server Address: http://bi.your.domain

Stat Server Port: 8080

This, so the statistics data can reach the separately deployed Business Intelligence server.

When installing the Business Intelligence server, take the following into consideration:

If you need to modify the value entered in the bullet above later, the value is written to:

You can modify the central.orchestra.url property later if the central Orchestra server changes host name. This requires restart of the Business Intelligence server to take effect.

This section describes the two options for accomplishing session sharing between the Orchestra and the Business Intelligence server.

Locate the section that looks like this:

Inside the brackets, add the proxy server IP address that the BI server will use when communicating with Orchestra. For networks that use both IPv4 and IPv6 you should add both addresses.

Example:

 

If each server is mapped to a subdomain of a common parent domain name, the cookie same-origin policy is not violated and session information can be shared. For same-domain policy installations, each IP must be mapped to a subdomain of your main domain name in the DNS server your users use to connect to Orchestra.

The cookie domain setting needs to be forced. This is done, by editing the file [install dir]/conf/shiro.ini on the Orchestra host and adding the cookie.domain property, as in the following example:

Please note that there have been reports of Internet Explorer users having to add the two full domain names to the browser's list of Trusted Sites in order for the cookie to be passed to both hosts.

An alternative is to use a reverse proxy / load balancer in front of both servers that has the capability to route requests to different backends depending on the context path of the request.

 

In this scenario, the user browser only sees proxy.yourdomain.com and thus the same-origin policy is not violated. Session info is safely shared.

Qmatic does not provide or support reverse-proxy or load-balancing software. However, for convenience a sample configuration for HAProxy is provided below. HAProxy is a free load-balancing software available for major Linux and Unix operating systems.

The following snippet from a sample HAProxy configuration routes requests to two different backends depending on the request path:

This sample would naturally need to be updated with IP's, port numbers, host names etc. applicable to the customer's infrastructure as well as other required elements of a functional HAProxy configuration. The snippet above only deals with the routing part relevant to the reverse-proxying mechanism and should be.

When using the reverse-proxy approach we need to change a few of the configuration settings we make sure that URL's to the Orchestra and Business Intelligence servers point to the IP or host name of the reverse-proxy and not directly at the servers.

This needs to be updated in two locations:

 

E.g. make sure that the URL in the Orchestra Home page uses the reverse-proxy address instead of the direct IP or host name to the Business Intelligence server.