ARS 7.x Topics
From ARSWiki
Contents |
ARUser Compatability
Known Issues
- 7.0 introduced table field preferences (add/remove/order columns)
- If using a preference server that predates 7.0, the table field preferences can not be saved
ARServer Compatability
Known Issues
- Unicode Support
- From Remedy's Support web: Due to an inconsistency in the way ARS meta data was stored in previous non-Unicode compliant versions of ARS (including ARS 6.3) you currently cannot upgrade to an ARS 7.0 server running on a Unicode database. Even if you are running an older version of ARS on a Unicode database, you can only migrate (not upgrade) your applications to a 7.0 server running Unicode.
ARServer 7.0 Installation Issues
Linux
Installing on CentOS 4.3
CentOS is a flavor of linux that claims 'binary compatible' with Red Hat Enterprise Linux ES. The version number between the two distributions is the same, so CentOS 4.3 is comparable to RHEL ES 4.3. When installing arserver on linux, the installer script checks for a 'supported' flavor/version of linux. This is done bye checking for a package that meets the following regular expression:
$_VERSION" : ".*release-\([0-9].*\)-.*
To install arserver on CentOS, apply the following patch to the ar_install script. If you are unsure of how to apply a patch, see the manpage.
--- ar_install.orig 2006-08-13 01:45:14.000000000 -0400
+++ ar_install 2006-08-13 02:23:02.000000000 -0400
@@ -4199,6 +4199,24 @@
fi
fi
+ # Looking for CentOS Enterprise Server
+ _VERSION=`/bin/rpm -qa | egrep -i "centos" | egrep -i "release"`
+ if [ "${_VERSION}" != "" ]; then
+ # Advance Server Version RedHat 2.1 or Greater
+ _THIS_VER=`expr "$_VERSION" : ".*as-\([0-9].*AS\)-.*"`
+ if [ "${_THIS_VER}" != "" ]; then
+ _VERSION="${_THIS_VER}"
+ else
+ _THIS_VER=`expr "$_VERSION" : ".*release-\([0-9].*\)-.*"`
+ if [ "${_THIS_VER}" != "" ]; then
+ _VERSION="${_THIS_VER}"
+ _PLATFORM=linux
+ else
+ _VERSION=""
+ fi
+ fi
+ fi
+
# Looking for SuSE Linux Enterprise Server
if [ "${_VERSION}" = "" ]; then
_VERSION=`/bin/rpm -qa | egrep -i "sles" | egrep -i "release"`
@@ -4323,6 +4341,15 @@
fi
fi
+ if [ "${_THIS_VER}" = "" ]; then
+ _THIS_VER=`echo ${VERSION} | egrep -i ""`
+ if [ "${_THIS_VER}" != "" ]; then
+ LINUX_TYPE="RedHat LINUX ES"
+ VERSION=`expr "$_THIS_VER" : "\([0-9].*\).*"`
+ MIN_LINUX_VERSION=$MIN_LINUX_ES_OS
+ fi
+ fi
+
VerCmp "$VERSION" "$MIN_LINUX_VERSION"
if [ $? = 2 ]; then
FatalError "Operating System must be $LINUX_TYPE $MIN_LINUX_VERSION or later"
Oracle
Can Not Use Existing Oracle Tablespace
It is not possible to install ARServer into an existing Oracle tablespace in version 7.0. Providing a tablespace name during the install on *NIX will cause the ar_install script to drop and recreate the tablespace. This could be devastating if there are other applications in that tablespace.
A workaround is to extract all embedded tarballs and tailor the arsystem.ora sql script to work properly, and execute it manually before running the installer and choosing the upgrade option. If you choose to use this workaround you will need to:
- Use arcache and arreload as User and Group forms are not created or populated.
- Manually load User, Group, and other bundled objects from the samples directory.
Note:This is fixed in ARServer 7.01
Applies to:
- ARServer 7.0 GA
- ARServer 7.0 patch 1
General
Fresh Install Message Catalog Data Import Failure
Doing a fresh install of ARServer with all languages selected (single and multi-byte) results in arx import errors for the form 'AR System Message Catalog' because the import exceeds the 2000 record limit. All languages includes:
- French
- German
- Italian
- Spanish
- Japanese
- Korean
- Simplified Chinese
The terminal output will show entries like this:
Import completed with errors:
341 Records were imported to form AR System Message Catalog; 212 Records were not.
Error importing Japanese MessageCatalog data.
Applies To:
- ARServer 7.0 GA
- ARServer 7.0 patch 1
Workaround
Generate and put in place an arsystem.lic file before running the installation. This can be accomplished one of two ways:
- Use another arserver and add the AR System Server license to that server. The host ids will not match, but arserverd will still generate a valid arsystem.lic file. Copy the generated arsystem.lic file to /etc/arsystem/<server>/arsystem.lic.
- Run the install twice, adding the license after the first install, followed by a re-install (toss all the old data, files, etc.; with the exception of the arsystem.lic file).
Duplicate Login Names in User Form Prevents Upgrade
Starting in version 7, there is a unique index and constraint on the Login Name field in the User form and user_cache table. Upgrading a 6.x or prior version to 7.x or higher version will currently fail if there are duplicate entries. (as of 7.01)
ARServer 7.0.1
Installation Issues
Issues with Oracle Unicode Upgrade
This applies if you are upgradeing an existing (6.3 and earlier) unicode database.
Symptoms
The ar_install script exits with the following output:
Running DB upgrade. This may take several minutes .... Running DB upgrade..... /* Fri Oct 13 10:03:35 2006 */ Start of Stage 1 of 2 /* Fri Oct 13 10:03:35 2006 */ End of Stage 1 of 2 /* Fri Oct 13 10:03:35 2006 */ Start of Stage 2 of 2 /* Fri Oct 13 10:03:35 2006 */ End of Stage 2 of 2 /* Fri Oct 13 10:03:35 2006 */ Start of Stage 1 of 21 /* Fri Oct 13 10:03:35 2006 */ Upgrade old field-lengths codeset=0 'windows-1252' errorCode=0 An error was encountered during the upgrade of the ORACLE database ./ar_install: test: argument expected
Workaround
Before Running the Upgrade Installer
Remove all the direct sql filters and escalations from your server prior to performing the upgrade.
After Running the Upgrade Installer
If you ran the upgrade installer and the upgrade failed as illustrated above, the following steps can be taken to restore your arserver to it's previous release. Once arserver is restored, perform the above workaround.
Update the control table to the previous schema version:
SQL> update control set dbversion = <schemaversionid> SQL> / 1 record updated SQL> commit SQL> /
<schemaidversion> is the version of your arschema prior to the upgrade. The following table can be used to update your dbversion:
| arserver | dbversion |
|---|---|
| 6.0 | |
| 6.0.1 | 20 |
| 6.3 | 21 |
| 7.0 | 22 |
Once this value is restored, the server side binary files need to be restored. On unix, the old directories are backed up in the arsystem installation directory. The backup directories are suffixed with a .bak extension. Remove the 7.0.1 directories and replace them with the backup directories.
Perform the first workaround (remove direct sql workflow) and re-run the installer.
General Issues
Memory Leak
This has been addressed in 7.0.01 patch 001
7.0.01 that it is not production ready. We implemented this in a production environment, only to find massive memory leaks in the product. The arserverd process will continue to run fine until it reaches the upper limits of the 32-bit memory address space (~4gb), at which time it will crash.
Symptoms
We observed between 600-700mb of additional memory allocation on our systems per day until we reached that upper limit. Our system handles ~200 support people concurrently, though I am not sure if this has a bearing on the speed at which memory is allocated.
Workarounds
Pre-release Patch
We were given a patch (which will become the patch 001 for 7.0.01), but it is pre-restricted release, which I am being told means it will be 3 or more weeks before the patch is at the general release level. Trying to save anyone the headache in case they planned to venture down this road any time soon.
Relavent Environment Info: - Oracle 9i with AL32UTF8 character set - Oracle 10g client - Solaris 9 - ARS 7.0.01 - Mixture of clients, ranging from 5.x to 7.0.01
I have been told the same problem has been exhibited on Linux as well. Not sure if it pertains to the db, the client versions, the character sets, etc.
Patch 001
Wait for patch 001. This is scheduled to be available on 2007/01/15.
ARServer 7.0.1 patch 001
Email Engine
Variable Substitution Problems
If using variable substitution in html email templates, values that begin with "www." "ftp." "smtp." among other protocols, do not substitute properly. Consider the following example:
FieldA: www.google.com Email Template Snippet:
please visit our <a href="site#$$FieldA$$#/test.html</a>
This will evaluate to the following in the html email:
please visit <a href="<a href="">www.google.com</a>/test.html
Basically, the variable is wrapped in the following tags: "<a href="">" and "</a>"
