Archive

Archive for the ‘7.1’ Category

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

ARSystem 7.1 – Status History

September 9th, 2007

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

ARS 7.1 – License Enforcement System

September 3rd, 2007

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

One of the biggest changes for version 7.1 is the change in the License Enforcement System. For years BMC partners like us have raised issues with the licensing system. It was too slow, untrusting of the customer and purging licenses was just a direct disaster with license keys that had to match up and sometimes got lost. All in all very confusing for the partners and the customers alike.

So I was pretty interested to see what has changed in the new version and wow, I’m quite impressed. The new system provides a great deal of flexibility and gives the customer a freedom that was not seen before. Also for us consultants this makes life a lot easier. Instead of having to wait for a license before we can show a product to a customer now we can install it on an environment, get a license for it and show the customer without any waiting in between. This will greatly enhance our ability to give Demos and show the products.

So what has really changed in the system? For one the whole license key mess has been cleaned up. From now on you can say that you have a license, how many of it you have and press save. No pesky Start, Expiration Date or License keys that are case sensitive. Here’s a screenshot of an example server, click to enlarge:

Overview of Licenses

As you can see only the AR Server license needs a key. In my case I have a temporary license which you can download from the BMC Support Website. All other licenses don’t need a key.

Of course what is important to remember is that only the license keys have disappeared, not the licenses themselves. That means that if you want to use 50 floating user licenses you will still have buy and pay maintenance for them.

There are two mechanisms that BMC can use to check on the license usage. One is an automated generation of a license use file. This is stored in the DB directory on the server. It records the number of licenses installed and the number of licenses in use. This file is updated about once every 45 minutes.

The other way is to generate a license report from the user tool. This reports takes a from- and to-date and will generate a summary of licenses used in the specified period. Below a screenshot of this report in Excel. Of note is that I appear to have used 3 fixed Incident Management licenses where none are defined. That should not really be possible I assume.

License Report

I don’t know how BMC wants to check the license usage at their customers. As far as I know there are no requirements currently in place that a customers sends a license report each year to BMC, but of course this can change. Also third-party developers that are dependant on BMC for licensed applications might not be altogether happy with this step. Then again I don’t know any company that uses the Licensed option for their application except BMC.

Conclusion

This is a real step forwards for BMC in regards to licensing. I’m really happy that they decided to make it easier for partners to implement products and show demonstrations. I will be interested to see how this plays out ‘in the field’ and how licenses will be implemented by the customer. At least it will save a lot of people a lot of headaches when installing ITSM7 on a customer site.

7.1, arsystem, bmc, new in 7.1

ARS 7.1 – Forcing and allowing password changes

September 3rd, 2007

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.

Password Change - User functionality (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.

AR Admin Console, new Password Config Option  Configuration Options for Password Change

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

ARSystem 7.1 – Installation

September 2nd, 2007

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.

AR Server 7.1 Administration Server Information

7.1, arsystem, bmc, installation, remedy

7.1 Released

September 1st, 2007

Version 7.1 is released, right on schedule.

I hope I will have time to have a first look at it this weekend.

7.1, arsystem

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