Remedy AR System blog

ARSocial is a Twitter – BMC Remedy AR System integration that allows you to publish tweets, replies, direct messages as well as have an overview of your friends timeline, a search option and mentions. Because it is based on the AR System it can be fully integrated into the ITSM Suite as well as custom built applications. The plugin and application are open source and released on with a BSD style license. Please be aware this is only a ‘preview’ release and is not quite ready for production use.

Architecture

The ARSocial application consists of several parts:

• ARDBC Plugin for listing tweets, mentions, direct messages and search

The ARDBC Plugin treats the twitter feeds (friends, direct messages, search) as a database source. Because of the speed of the Twitter API we can do fast searches and show all relevant information, mentions and direct messages. It also allows for the creation of tweets, replies and direct messages.

• ARSocial Console form, for an overview of all twitter related items

This will be the main form for the users of the application. It is meant to keep an overview of all tweets that are sent by friends, mentions of the twitter account and searches (for example tweets that mention your company name)

• Vendor and Regular forms

Vendor Forms are built from the ARDBC Data sources to show the information in the Tables of the console. Regular forms are used to store sent Tweets and Direct Messages.

All items and source code can be found in the download package.

What you will need

• BMC Remedy AR System 7.5 server
• Midter 7.5
• Remedy Developer know-how
• Plugin Server know-how
• Java know-how
• A twitter account
• An AR Server that you can break without getting people angry at you (really, I’m serious)

You can download a ‘developer preview’ of the application here: arsocialpreview

at the moment there’s only standard twitter client functionality implemented, and there is no direct integration into the ITSM Suite, however because of the architecture including Vendor Forms it is quite easy to integrate into any itsm and custom built applications. Over the next few weeks I will expand the plugin and the application.

For now please be aware there are several open issues, including ordering of tweets in the table fields and missing functionality in the stand-alone application.

Please provide feedback on BMCDN communities, contact me on twitter or send an email.

remedy

The Remedy Java API can  be used to get a lot of information. We typically either get information from Forms, or we get configuration information from the server itself. In this example we’ll be looking at how to get application information back from the ARSystem.

For that we use the SHARE:Application_Properties Form. This form stores all information about installed BMC applications. It is typically installed if you install ITSM 7.x (It is standard installed on ARSystem 7.5)

The entries in this form are not stored and readable in a very user friendly way. Sometimes we just want to information at a glance about which applications are installed, which patch level we’re at and which languages are there. What our Java application does is it will query the form, get the separate entries that belong to the same application together and print it on the screen.

Let’s have a look first at how we get the information from the ARSystem form. First we define which fields we want to get back. For this we create an array of integers of the field id’s:

int[] fieldsFromShareApp = new int[2];

fieldsFromShareApp[0] = 400081800; // Property Value

fieldsFromShareApp[1] = 400081600; // Application ID

Then we create a QualifierInfo object, which is our query that we will run. The easiest way to creat an object like this is to use the following syntax:

QualifierInfo qualSearch = context.parseQualification(“SHARE:Application_Properties” , “‘Property Name’ = “Name”");

 

We call the parseQualification function and give it two parameters: the Form name and the qualification as we would put it in the form. Here we use the Database names for the fields, we can also use the field labels. In that case we would use the ParseQualification() function with three parameters: Form name, View Name and Qualification.

 

Once we have the QualifierInfo object we use it to run the search:

 

List<Entry> foundAppNames = context.getListEntryObjects(“SHARE:Application_Properties” , qualSearch, 0, 0, null, fieldsFromShareApp, false, null);

This will give us a List of Entry objects that match the qualification.  For us these are all entries where the Property Name field holds the value Name. For the other options that we can specify here please consult the ARS Java API Javadoc documentation.

We can see how entries are returned by using the .size() function of the List<Entry> object:

System.out.println(foundAppNames.size() + ” Applications in SHARE:Application_Properties”);

 

We repeat this step to also retrieve the version, patches and languages installed on the server.

Then we loop through our applications to match up the  names with versions, patches and languages:

for (int i = 0; i < foundAppNames.size(); i++)

            {

            Entry foundApp = foundAppNames.get(i);

      String appName = foundApp.get(400081800).toString();

      String appID = foundApp.get(400081600).toString();

      <……….>

 

In the above function we browse through the Entry Objects that we have and set the appID String to hold the application InstanceID. We use this ID to compare it to the Application Instance ID in the version information.

 

      // now find the versions

      for (int v = 0; v < foundAppVersions.size(); v++) {

            Entry foundAppVersion = foundAppVersions.get(v);

            String appIDVersion = foundAppVersion.get(400081600).toString();

                  if (appIDVersion.equals(appID)) {appVersion = foundAppVersion.get(400081800).toString();

                        }

                  }// end for loop versions

 

At the end we display the information in a readable format for the user:

System.out.print(appName + ” Version: ” + appVersion);

      if (appPatch != null) {

                        System.out.print(” Patch ” + appPatch);

            }

 

      if (appLanguagepack != null) {

                        System.out.print(” ” + appLanguagepack);

            }

                  System.out.println();

      } // end for loop appNames

 

 

You can find the full source code to the application here: arsystemapplicationinfo

java, remedy

Wow, there are sure a lot of new options in ARS 7.5, a lot of improvements in the GUI, Scalability and other fun stuff. Since I could spend a few months detailing all the new functionality I urge everyone to look at the ‘What’s new in ARS 7.5′ documentation on the BMC site.

I will go through some of the (I think) best new options in AR System 7.5 in a few posts, starting off with some GUI stuff and going on to the CMDB (which has a complete new user interface!).  Unfortunately I have a few projects lined up at the moment at work so posting will be a bit light over the next few weeks.

One of the coolest (and easiest for developers) GUI enhancement is the Auto-completion. Where in Remedy we used to have to create workflow where a user would press enter in a field and search the database this is now automatically done by the Midtier. Here’s an example of how it looks:

Here I just typed an a into the field, the midtier gave me back all the menu items that have an a in the value. This is great news for all the users who want to use the keyboard only and not be bothered with mouseclick on menu items.

The option is simply enabled by attaching a menu to a field and setting the following option in the field properties:

It is under the Display Options in the Developer Studio (which I’ll look at in another post). Unfortunately this option only seems to work in the Midtier at the moment.

7.5, remedy

Remedy ARSystem 7.5 and CMDB 7.5 were released this weekend and have a whole lot of new options, including a 100% java api (so no native libraries anymore). I will write about some of the new options here once I have explored them.

7.5, remedy

Creating a test post for the twitter integration. http://twitter.com/sebas

remedy

Using the Java API we can get all kinds of information about the AR System server.

In this example we will get information back about the server, operating system and databank. We are using the getServerInfo(requestList) method for that.

We first specify which information we want to get back from the server:

int[] requestList = new int[7];
requestList[0] = ServerInfo.DB_TYPE;
requestList[1] = ServerInfo.SERVER_IDENT;
requestList[2] = ServerInfo.OS;

We create a new integer array and fill it with the static values that we want. For example ServerInfo.DB_TYPE is the type of database. If you want to have a complete list of all the information you can get back refer to the ServerInfo class in the javadocs.

Now we go to the server and ask for a ServerInfoMap of the information. We use the .getServerInfo() method from ARServerUser for that.

ServerInfoMap serverInfoMap = context.getServerInfo(requestList);

What we have now is an object that is filled with the information we requested, we can get this information out by using the .get method of our ServerInfoMap object. like this:

System.out.println("Database Type: " + serverInfoMap.get(1));
System.out.println("Database Version: " + serverInfoMap.get(Constants.AR_SERVER_INFO_DB_VERSION));
System.out.println("Full Hostname: "+ serverInfoMap.get(Constants.AR_SERVER_INFO_FULL_HOSTNAME));

As you can see for the key we can use either the ServerInfo.INT, Constants.INT or the normal integer values.

You can download the full source code here: arsystemserverinfo (don’t forget to change the servername)

7.1, arsystem, java, remedy 7.1, api, ars, java

This article is part of the New in ARS 7.1 series

One of the new options in 7.1 is the option to disable the Status History for forms. This has the advantage that the Status History tables in the database do not need to be updated. Theoretically this could save a lot of time.

Functionality

The Status History of a form can be disabled by going to Form Properties and checking the ‘Disable Status History’ button on the ‘Basic’ tab. This has to be done for each form separate.

Test

 To test out this new functionality I built a small application (Download here to test yourself). It has two forms, one with Status History enabled and one disables. Both forms have 1000 records. Separate is a Display Only field with a button and four fields, each recording the time it takes to set the status of all records to Assigned and back to New. The four times it records:

• Changing status of 1000 records with Status History
  • Using Active Links
  • Using Filters

• Changing status of 1000 records without Status History
  • Using Active Links
  • Using Filters

 The improvements speak pretty much for themself, keeping in mind that the testenvironment is a bit extreme.

Testhardware: VMWare Workstation on Core 2 Due 2.0 Ghz with 2 Gb RAM. VMWare RAM: 1552 Mb

The following times (seconds) are averages over 5 tests:

	Active Link Push Field	Filter Push Field
With Status History	34.2	4.8
Without Status History	32.8	3.8

As expected the biggest percentual gain is on the server, almost 20% !

 SQL

If we look at the SQL that gets generated when updating one record we can see how we get there. this is the SQL that gets generated when updating a ticket in the user tool with Status History enabled:

*/BEGIN TRANSACTION
*/OK
*/UPDATE T1676 SET C7=1,C5=’Demo’,C6=1189331127 WHERE C1 = ‘000000000000001′ AND ((C6 <= 1189331110) OR (C5 = ‘Demo’))
*/OK
*/UPDATE H1676 SET T1=1189331127,U1=’Demo’ WHERE entryId = ‘000000000000001′
*/OK
*/COMMIT TRANSACTION
*/OK
*/SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1676 WHERE C1 = ‘000000000000001′
*/OK
*/SELECT entryId,T0,U0,T1,U1,T2,U2,T3,U3,T4,U4 FROM H1676 WHERE entryId = ‘000000000000001′
*/OK

As you can see first we update the ticket table (T1676), then the status history (H1676), after that we retrieve the ticket first, and then again the status history.

The following SQL is without Status History:

*/BEGIN TRANSACTION
*/OK
*/UPDATE T1677 SET C7=1,C5=’Demo’,C6=1189331073 WHERE C1 = ‘000000000000001′ AND ((C6 <= 1189331035) OR (C5 = ‘Demo’))
*/OK
*/COMMIT TRANSACTION
*/OK
*/SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1677 WHERE C1 = ‘000000000000001′
*/OK

 As you notice, 50% less SQL statements! This is of course only because there is no further workflow on the form, large forms with lots of checking and other workflow (push fields) will not notice too much performance improvement. However this will drastically improve the performance of mass updates through the Atrium Integration Engine (the application formely known as EIE).

Database

When disabling the Status History functionality, all information in the H table is deleted, however the table itself is not removed from the database.

 Conclusion

Very neat feature, that on mass updates will improve the perfomance a lot. In normal daily use it is unlikely that users will have a notable performance increase when updating tickets, but of course it will ease up on the load of a database. It would perhaps have been nice to have a general checkbox to disable all Status History on a server.

7.1, arsystem, bmc, new in 7.1, remedy

This article is part of the ‘New in ARS 7.1′ series. 

Part of the new functionality in ARS 7.1 is to allow Users to change their own password. The way BMC has implemented this with the use of a new Form called ‘User Password Change’, permissions are set to Public and an Entry Point is enabled so it will show up on the application list on the Home Page. On systems with LDAP authentication this will manually have to be disabled, on Mixed Authentication systems some other small check might have to made if a user can change his or her password.

On the form the old password has to be entered, followed by a new password and a confirmation of that new password. It all looks pretty straight-forward for the enduser which is of course always good. After a click on the save button the password is saved, and the user can continue working without having to log out and in again. That is great news, and a big improvement over home-made change password tools.

The password change works on a v7.0 User Tool as well, with the exception that the User has to log in again.

 (Screenshot of Change Password functionality, click for full size)

Configuration

On the AR System Administration Console there is a new option to change the Configuration of the Password Change. This seems to work in several mysterious ways, including crashing the user tool when saving the record for the first time and not having a save button where you would expect one. However multiple options are available including expiration, warning and disable windows for passwords. There are some standard rules enforced, which can be disabled. There is another option to add other checks in the new password as well.

  

Conclusion 

Overal it looks feature complete, and the standard rules should satisfy the Security Department rules of most companies. Of course in a lot of cases authentication will go through LDAP, making this new functionality one more thing that has to be disabled on a new installation. It is certainly a big improvement over having to write your own functionality in previous versions.

7.1, arsystem, bmc, new in 7.1, remedy

After celebrating that 7.1 was released (ok, not really) I spent a few hours installing it with several other components today. I decided to do a typical upgrade of ITSM7, not a fresh install. I have not looked at the compatibility matrix yet but suppose ARS 7.1 should really work with ITSM 7.0.2.

I installed 7.1 on the following machine:

• Hardware:VMWare
• OS: Windows 2003 Server
• DB: MS-SQL 2000
• Webserver: IIS 6
• Java 1.5 Update 12

Remedy products installed:

• ARS 7.0.1 patch 3
• ITSM 7.02 patch 4, including: IM, PM, CM, SLM, SRM, KM

I installed using the mininum options, only adding Webservices to the mix.

All new versions installed:

• ARS 7.1
• Midtier 7.1
• Approval Engine 7.1
• Assignment Engine 7.1
• User Tool 7.1
• Admin Tool 7.1

Installation of AR Server 7.1

As mentioned above, the Server install was an upgrade from 7.0.1 p3, the installer did not give any error messages, but the error log showed some index violations (makes sense, the data was already there) and mentioned that Sample data was not requested (it was).

There are no new options at all in the 7.1 installation as compared to the 7.0 installation, so there is not much to review except to say that the English Windows installations always seem to work out just fine. As I have noticed with several customers once you start throwing in other languages, Unix and perhaps on Oracle DB things tend to mud up a bit. I’m really looking forward testing this install on Solaris with an Oracle DB and throw in a few umlauts.

 Installation of ARS 7.1 User Tool

Went without any problems, logged in and saw the new Change Password functionality, which I will review later.

Installation of ARS 7.1 Admin Tool

The new Admin tool did not install on my VMWare, which already was an upgrade from 6.3. It did install nicely on my normal Windows XP Professional machine, so I guess it is a one-off failure. It all looks good, but of course there are the features that got moved to the User Tool. I’ll review them later.

Assignment / Approval Engines.

These proved to be horribly boring to install, however both wanted a reboot after the install.

Midtier 7.1 Installation

I uninstalled 7.0 midtier and the Atlanta ServletExec. Installation was smooth and painless, with the BMC installer suggesting I install Tomcat. Also the IIS redirector was automatically installed.

Conclusion

As with version 7.0, installing ARS on a Windows platform is quite easy. No new features were introduced that needed additional installation, and  an upgrade from 7.0 was easily achieved. I’m looking forward to giving the new functionality a spin and having a look at the new Java API.

7.1, arsystem, bmc, installation, remedy

On the BMC Developer Network there is an article detailing the new functionality in ARS 7.1, which should arrive early September. (The unofficial date is ready for download at 31 August, but that is today and I have not seen anything yet).

Most interesting for Java developers like me will be the Java plugin server. I’m hoping it has the same capabilities as the ‘old’ C plugin server. Since java plugin server can run C plugins as well I assume that is the case.

BMCDN : What’s New in BMC Remedy Action Request System 7.1.00

7.1, arsystem, bmc, java, remedy