Archive

Archive for the ‘java’ Category

How to get ITSM Application information using the ARSystem Java API

January 26th, 2009

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

Get License info using the Remedy ARS Java API

December 29th, 2008

Using the Remedy ARS Java API we can get all kinds of information about the licenses that are installed on the server. These can be server licenses (ARServer, Fixed, Floating, etc.) or application licenses (Incident Management, Problem Management, etc).

What we first of course do is get a proper ARServerUser, as usual we will create one hardcoded for the example.
ARServerUser context = new ARServerUser("Demo", "", "","192.168.184.128")

Now we use the ARServerUser.getListLicense() method to get a List of LicenseInfo objects:

List<LicenseInfo> licenseInfo= context.getListLicense(null);

What we do now is walk through the List<LicenseInfo> that we got (in licenseInfo) and show some information about it.

for (int i = 0; i < licenseInfo.size(); i++) {
LicenseInfo licInfo = licenseInfo.get(i);
System.out.println(licInfo.getlicType() + " " + licInfo.getNumLicenses() );
}

We show the Type of the license (ie. BMC Incident Management Application, User Floating, etc) and the number of licenses.

If you want to see all the information that we can get back about license information have a look at the LicenseInfo object in the Javadoc Documentation.

You can download the complete source for this example here:arsystemlicenseinfo

This entry is part of the BMC Remedy ARSystem Java api series

7.1, arsystem, java , , ,

Java – Get Server Information

December 21st, 2008

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 , , ,

ARS 7.1 – New Java API

September 10th, 2007

This article is part of my New in ARS 7.1 series and my Java ARS API series.

One of the major changes for ARS 7.1 is that it has a new Java API. It looks and feels like it is a complete rewrite from the original API. From the BMC documentation:

The primary goals of this API revision are to simplify the interface and eliminate drawbacks of the 7.0 API. Changes include:

  • Simplified interface.
  • More Java-friendly.
  • Use of Java typed-collections.
  • Improved stability, performance, and ease of deployment.
  • Increased developer productivity by means of better named API methods, intellisense of IDEs, and documentation.
  • Drive towards a “pure” Java implementation and eventually eliminate Java Native Interface (JNI) use.

While this is all true, one of the main drawbacks is that you almost completely have to rewrite old Java applications if you want to use them with the new API.

However if you are writing new Java applications this new API is the best release ever. I only played around with it a short time but was really impressed by how it all fits together. Lots and lots of irritating String wrappers have been dropped, multiple ‘nested’ items have become uncluttered and the toString functions now returns nice Strings instead of garbled nonsense.

Sample Code

For the sample code (and all ARS Java API 7.1 code) to work you will need Java 1.5.0_12 or later. I personally use Eclipse 3.2 Europa (Eclipse IDE for Java Developers) as my development environment, however you can of course use any.

Full source code of samples with comments download (click)

Let’s take a look at creating a new Entry in a Form (yes, they are called Forms now!)

ARServerUser context = new ARServerUser("Demo", "", "", "localhost");
Entry newEntry = new Entry();

newEntry.put(7, new Value(0));
newEntry.put(2, new Value("JavaSubmitter"));
newEntry.put(8, new Value("Short Description"));

try{
System.out.println(context.createEntry("XQSR:JavaExample", newEntry));
}
catch(ARException arException){
arException.printStackTrace();
}
}

Yes, that is indeed all, no need for anything more. The Entry Class now holds a map with the Field IDs (integers) and Value objects. This is a great improvement over the EntryItem[] entryList = new EntryItem[3]; ‘fun’ that was in previous API versions.

As for retrieving an Entry, changing values and submitting it again the following example should give a quick impression:

ARServerUser context = new ARServerUser("Demo", "", "", "localhost");

int[] fieldIDsToRetrieve = new int[6];
fieldIDsToRetrieve[0] = 1;
fieldIDsToRetrieve[1] = 2;
fieldIDsToRetrieve[2] = 3;
fieldIDsToRetrieve[3] = 5;
fieldIDsToRetrieve[4] = 6;
fieldIDsToRetrieve[5] = 7;

try{
Entry retrievedEntry = context.getEntry("XQSR:JavaExample", "000000000000001", fieldIDsToRetrieve);

for(int i=0; i<fieldIDsToRetrieve.length; i++){
System.out.println(retrievedEntry.get(fieldIDsToRetrieve[i]) );

}
retrievedEntry.put(8, new Value("I am updated"));

context.setEntry("XQSR:JavaExample", "000000000000001", retrievedEntry,new Timestamp(0), 0);

}
catch(ARException arException){
arException.printStackTrace();
}

We fill an integer array with all Field IDs we want to retrieve, make a call to the DB, print out the values, set another field with a value and save it again. Again, no things like:

entry.setEntryItems(entryItems);
entry.store();

Where we had to set an EntryItems object and fill it with Field IDs and Values separate, we now go to the Entry object, and specify where to save it.

There’s a whole lot more to this API than I said here in this small article, unfortunately I don’t have too much time explore it all at the moment. Once I start writing more applications with it I’m sure other new functions and possibilities show up.

Conclusion

A great step forward for the ARS Java API. Of course it is never fun to break backwards compatibility with version 7.0 and earlier, but at of course those applications will still run with the old libraries against a 7.1 server. If you start writing a new Java application and use the 7.1 API you’ll never want to return the old one.

Full source code with comments download (click)

7.1, arsystem, java, new in 7.1 , , ,

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

August 31st, 2007

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