|Remedy||AR Server v7.0.0 or greater|
|Web Application Server|| |
Java Servlet Container (Servlet spec 2.4, JSP spec 2.0)
|Java||Java 1.6.0 or greater - either 32-bit or 64-bit|
|Architecture||Click for Architecture Requirements|
For a new install, download the full installation package. The zip file contains a Windows executable that can be used to automate the process. If you do not have access to a Windows machine with the ability to connect to your Remedy server, the zip file also contains the Remedy definition files, Remedy data files, and web application files necessary for a manual installation.
If Kinetic Request will be installed on a Java EE web application server other than Apache Tomcat, you will also need to download the upgrade package, which includes Java EE web archives specific for those servers.
For complete installation instructions, see the Kinetic Request Installation Guide.
The 5.1.3 upgrade requires that Kinetic Request is currently at version 5.1.2. If you are on a version prior to 5.1.2, see the appropriate upgrade section for each successive version on how to upgrade your system to 5.1.2 before continuing. Typically you may skip the web application portion of any prior upgrades as the web application will again be overwritten in the 5.1.3 upgrade.
Upgrading From 5.1.2
- Download and unzip the upgrade package.
Remedy Workflow and Data
- Use a Remedy Administrator or BMC Developer Studio tool to import the ARS/kineticSR_v5.1.2_to_v5.1.3_changes.def ARS definitions file into your Remedy system. Be sure to choose the option to "Replace Objects on the Destination Server" when importing.
- Use a Remedy Administrator or BMC Data Import tool to import the Data/Group.arx ARS data file into the Group form on your Remedy system. Select Add All for the mapping.
Web Application - Using Tomcat as an example
Upgrade Kinetic Request
- Update the Core Web Application
- Stop the Tomcat service
- BACKUP your existing kinetic directory located at <tomcat>/webapps/kinetic.
- Copy the Web/apps/kinetic.war file from the extracted upgrade package into the <tomcat>/webapps directory. If you are using WebSphere or WebLogic, instead use the .war/.ear file in the associated subdirectory, which includes configuration items specific to those servers.
- Clear the cached JSP files.
For Tomcat, delete the entire <tomcat>/work/Catalina/localhost/kinetic directory.
- Delete the existing web application located at <tomcat>/webapps/kinetic.
- Restart Tomcat and the web application archive will automatically deploy.
- Log into the Admin Console and configure the necessary properties. The default web admin account is admin/admin. The Admin Console's address will be like http://<webserver>:<port>/kinetic/AdminConsole
- Copy back the themes directory and any other customized files from the backup made in step 2.
The following bugs were fixed in this release:
2566 - Fix permissions on the submission console
2569 - Cannot create a catalog with a description over 254 characters
2570 - Cannot import a service item that contains the catalog definition unless the user is a Remedy administrator
2602 - Transient questions do not save the pattern label
2616 - Possible null pointer exception when immediately loading a previously submitted page
2617 - Ensure certain parameter values are always encoded
2633 - The 'Max Number of Characters' field value is blank when modifying a Free Text question
2635 - Duplicate results on dynamic lists
2636 - Renaming a bridge qualification name does not update references that use it
2637 - Changing a bridge qualification on a dynamic default wipes out the bridge parameter mapping without warning the user
2639 - Unable to clone in certain environments
2643 - Permanent timezone offset cookie causes problems around daylight saving time
2644 - 'Read-Only' field is missing from the KS_SRV_ElementDialog form
2649 - Values of some template attributes can be passed to others when modifying
2496 - Add a new Remedy group to allow non-manager users to import/export service items (KS_SRV_Migrator)
2620 - Add 'Sort Order' to the results list of the KS_SRV_ContentEvents form
2632 - Incorporate an option to create a cookie that persists sessions across browser restarts
Two items of interest were added in this version that require additional setup in order to use them. If your organization does not wish to use these items, then no additional work is required.
Ability for non-manager users to import/export service items
Some organizations have found the need to have somebody other than the Request Manager or Survey Manager migrate the service items from the development environment to the QA / UAT environment. These users would not be members of the KS_SRV_Manager or KS_RQT_Manager groups, and would have no access to the Survey Author Console or the Request Catalog Console, and therefore would not be able to import or export service items.
A new group was added in v5.1.3 that would allow these users to import/export service items, but still keep them out of the Survey Author Console and Request Catalog Console.
To allow non-users the ability to import/export service items, simply add the user to the KS_SRV_Migrator Remedy group.
Persist user sessions across browser restarts
Some organizations have requested that Kinetic Request be able to retain user sessions across browser restarts. While this feature was added in v5.1.3, it is disabled by default.
It can be enabled by changing a value in the web.xml file located in the Kinetic Request web application deployment directory on your web server to indicate the name of the session cookie your web server uses. In a Tomcat deployment, the web.xml file will be located at <tomcat_base>/webapps/kinetic/WEB-INF/web.xml where <tomcat_base> is the base location of your tomcat deployment. If your organization uses a web server other than Tomcat, the file may be in a different location.
Near the top of the web.xml file, a new <context-param> element exists named SESSION_COOKIE_NAME. By default the parameter value is blank, which indicates this feature is not used.
<context-param> <description>The name of the cookie that is used to set the session id. If this value is set, sessions will be persisted in the browser between restarts. If this value is not set, session cookies will not be persisted between browser restarts. The value of this parameter should be set to the name of the session cookie generated by the web server, for most systems this will be 'JSESSIONID'. </description> <param-name>SESSION_COOKIE_NAME</param-name> <param-value></param-value> </context-param>
To enable the persistent user session, you will need to edit the web.xml file with a simple text editor such as Notepad, and change the <param-value> element to the name of the session cookie used by your web server. Tomcat uses the value JSESSIONID, other web servers may use a different value. You will need to consult your web server documentation to obtain the correct value.
<context-param> <description>The name of the cookie that is used to set the session id. If this value is set, sessions will be persisted in the browser between restarts. If this value is not set, session cookies will not be persisted between browser restarts. The value of this parameter should be set to the name of the session cookie generated by the web server, for most systems this will be 'JSESSIONID'. </description> <param-name>SESSION_COOKIE_NAME</param-name> <param-value>JSESSIONID</param-value> </context-param>