Java applications

iKnowBase comes with a number of web applications that comprise the server side components of iKnowBase:

Each of the applications are installed in a similar way. Also, there is no conceptual difference between a fresh install and an upgrade, although many application servers have shortcuts to reinstall a new version of an existing application. The install or upgrade process will vary from application server to application server. This chapter describes the generic concepts, while application server specific methods are described in appendixes.

Fresh install

For each of the java applications, you may need the following steps:

Before you start

The iKnowBase applications require an application server or servlet container that supports the Java Enterprise Edition Servlets release 3.0. For many application servers, you will need to configure a separate container for iKnowBase use.

ikbWebDAV requires deployment to context root / and will typically require a separate host (virtual host or separate server depending on application server) for this purpose as ikbViewer is also deployed to /.

Cluster support

The iKnowBase web applications in general support application server clustering and session replication, provided the load balancer is configured with session persistence / sticky sessions. See application server specific documentation for more details.

Exceptions:

Create data source

The iKnowBase web applications will look up the JNDI resource “jdbc/iknowbaseDS”, which needs to be JDBC data source referring to the iKnowBase database repository to use. For some application servers, you will first create a “connection pool” referring to the database, and then a “data source” referring to the data source; other times, you will only create a data source directly referring to the database.

The most important things to keep in mind are these:

Deploy the applications

Deploy the applications as required by your application servers, keeping the following in mind:

Security roles

During or after deployment, you need to configure security roles for the application. Again, the configuration method will vary from application server to application server.

ikbViewer

The ikbViewer has three security roles:

Note that it still possible to access iknowbase applications and content without being in any of these roles. However, without being in the IKB_USERS role, all content will be presented as the public user.

ikbStudio

The ikbViewer has a single security role:

ikbWebServices

The ikbWebServices has a single security role:

ikbBatch

The ikbBatch has a single security role:

ikbActiviti

The ikbActiviti has no security roles.

ikbProcessServicesWS

The ikbProcessServicesWS has no security roles.

ikbInstant

The ikbInstant has three security roles:

ikbWebdav

The ikbWebdav has three security roles:

Advanced topics

Deploy with “/ikbViewer” prefix

The iKnowBase Viewer application iknowbase-viewer-webapp-VERSION.war has traditionally been deployed to /ikbViewer, but is by default from 6.4 deployed to /. The application will support requests using the old context root /ikbViewer when deployed to /.

The application can still be deployed to /ikbViewer or some other path of the customers choosing, but the context root must then be explicitly changed during deployment.

Background

On a given listening port, the web server should handle all the iKnowBase applications as well as all other custom applications. A typical set of handlers (endpoints) could be this:

With the setup above, you can access iKnowBase-pages using “//server/mypagename”.

Deployments before iKnowBase version 6.4 used context root /ikbViewer for the main runtime application, resulting in access to iKnowBase-pages using “//server/ikbViewer/mypagename”

From an iKnowBase perspective, the following requirements must be met if you want to change the context root:

Update domain definition to match new endpoint

The final step is to make iKnowBase generate URLs to the new endpoints. From ikbStudio, edit the domain definition served by the endpoint, and update the relevant URL-prefixes: