This documentation supports the 18.08 version of Remedy Action Request System.

To view an earlier version, select the version from the Product version menu.

18.08 enhancements








This section contains information about enhancements in the version 18.08 of BMC Remedy AR System.

Related topics

Downloading the installation files

Known and corrected issues

Release notes and notices

Ability to customize the Server Group Dashboard of the Remedy Management Console

When you want to monitor any key metric on a regular basis, you can choose to customize the Server Group Dashboard of the Remedy Management Console by configuring any out-of-the-box flashboards on your server. The objects on the server group dashboard are now displayed through a flashboard with HTML rendering. HTML rendering offers more configurations to view the server group statistics. For more information, see Customizing the dashboard of the Remedy Management Console.

There is no change in the flashboard rendering for the rest of the forms.


Content specific precheck for a package

BMC offers content-level precheck for a package. Content-level precheck helps you add a more specific check to the package by checking a condition that you have set at the form level.

For example, when BMC offers a patch for Remedy IT Service Management and you are not using Remedy Asset Management, deploying a package containing fixes for Remedy Asset Management might result in errors. You can define a content-level precheck that will prevent deploying the Remedy Asset Management patch from being deployed in your environment.

The below screen illustrates the RDA:DeploymentPackageCheck form with the Content Deploy option.

For more information, see Content level precheck.

Ability to define a group of multiple payloads corresponding to a particular process

The new Processing Group Name field on the AR System Single Point Deployment Payload form enables an administrator to create a logical group of payloads that correspond to a particular process or a set of processes. This helps in avoiding multiple restarts while deploying payloads corresponding to the impacted process or set of processes.

The below screen illustrates the new Processing Group Name field on the AR System Single Point Deployment Payload form:

For more information, see Understanding Processing Group Name.


Asynchronous payload deployment

When you have multiple package content that includes payload, the status of the package changes to Deployed only when the package content including payload is successfully deployed.

For example, a package contains a definition file, a payload, and an arx file. When you start the deployment, first the definition file is deployed. Then the system prompts to run the arpayloaddeploymentutil.bat or arpayloaddeploymentutil.sh utility to deploy the payload. After the payload is successfully deployed, the system processes the arx file. Once the arx file is deployed the status of the package changes to Deployed.

Best Practice

BMC recommends keeping all payloads together in sequence.

Support for OAuth authentication by the REST API when integrated with Remedy Single Sign-On

From version 18.08, the Remedy REST API supports OAuth authentication when integrated with Remedy Single Sign-On.

As an AR System administrator, you can now configure the Remedy AR System server to access the client using the REST API call for OAuth2 authentication. In this case, Remedy Single Sign-On is the OAuth 2 provider, which returns an access token and a refresh token. Even if the access token is of a shorter duration, the refresh token has a longer expiration time. When the access token expires, you can use the refresh token to get a new access token. This ensures that you can use the system for a longer time without having to log in.

For more information, see Enabling OAuth authentication by the REST API with Remedy Single Sign-On integrated.


What's changed in this release

Enhancement Product behavior in versions earlier than 18.08 Product behavior in version 18.08
The ViewStat utility is removed.

This Java based utility helps to migrate the viewStat.dat file from version 9.0 and earlier to the new naming convention and directory structure that is applicable from version 9.1 and later for the multi-tenancy support in the mid tier.

You can create a new viewStat.dat file. When you shut down the Mid Tier the viewStat.dat file is automatically generated.

Upgrade Jackson jar files to the latest version. Jackson jar files version 2.9.0 are used. Jackson jar files are upgraded to the latest 2.9.5 version.
New filter XSSProtectFilterFromList in the web.xml file.

A new filter
XSSProtectFilterFromList
in the web.xml file helps you overcome the Cross Site Scripting (XSS) vulnerability.

In the config.properties file, you can exclude the filter list. For example:

#exclude filter list
#not applicable for xss
arsystem.
xss_arsys_exclude_list
=config.jsp

In the web.xml file, use the
XSSProtectFilterFromList
filter and provide the host name. For example:

<filter>

<filter-name>
XSSProtectFilterFromList
</filter-name>

<filter-class>
com.remedy.arsys.config.
XSSProtectFilterFromList
</filter-class>

<init-param>

<param-name>protect-param
</param-name>

  <param-value>
</param-value>

  </init-param>

</filter>     

 <filter-mapping>

 <filter-name>

XSSProtectFilterFromList
</filter-name>

  <url-pattern>/shared

/config/*</url-pattern>

  </filter-mapping>

New Waiting for Utility Run status on the AR System single point deployment status form. When a package deployment starts, the AR System single point deployment status form shows Pending deploy status. 

When a package deployment starts, the AR System single point deployment status form shows Waiting for Utility Run status. This prompts the administrator to start the arpayloaddeploymentutil.bat or arpayloaddeploymentutil.sh utility.

This also helps the administrator to avoid rerunning the arpayloaddeploymentutil.bat or arpayloaddeploymentutil.sh utility if the File Deployer process stops responding.

When the File Deployer process is up again, it automatically processes all payloads that have the Pending Deploy status. You need not run the utility again.

A dedicated log file for the ARSYS.ARF.ARMIGRATE plug-in The ARSYS.ARF.ARMIGRATE plug-in logs are collected in the

arjavaplugin.log file.

The ARSYS.ARF.ARMIGRATE plug-in logs are collected in the new ard2pplugin.log file.

This file is located in the <Install directory>/ARServer/Db directory.

Apart from the package GUID, the ard2pplugin.log file also displays the Package Name and Package Version.

For example:

<ARSYS.ARF.ARMIGRATE>
ARMigratePlugin:

starting deploy
 init operation.

<Package Entry ID
: 000000000000673

Package Name: SRM 1808,
Package Version:
SRM_18.08_180820-223030>
<ARSYS.ARF.ARMIGRATE>
ARMigratePlugin:
deploy package

item operation completed.
<Package Entry ID:
000000000010867
Package Name:

SRM 1808,
Package Version:

SRM_18.08_180820-223030>

Automatic cache sync for Mid Tier Whenever AR System Server successfully applies a deployment package, you have to manually sync the Mid Tier cache. Whenever AR System Server successfully applies a deployment package, any Mid Tier versioned at 18.08 receives a notification and can sync the cache automatically.
Was this page helpful? Yes No Submitting... Thank you

Comments