Share This:

You know what I like about Remedy? That it allows to me to quickly build complex applications. Things like approvals and authentication, which are difficult to manage are put together quite quickly using workflow. So if you need an application to manage your inventory, manage your holiday planning or even your lunch orders, Remedy will do the job. The range of functionality added by Remedy is great, but what if you need the application to do something that’s not available out-of-the-box? Well that’s my problem with Remedy, there’s a ceiling and it’s difficult to add new functionality. Yes, you can write your own plugins or try to accomplish it through web services, but it’s not straightforward and it doesn’t always integrate that well.


But here's the good news: Innovation Studio changed this. You still have the ability to build applications using a workflow-based design, but if the functionality you’re after isn’t there, you can just build it yourself. A spoiler alert should probably be in place here: we'll be looking at some Java code. But rest assured, we'll keep it as simple as possible.


Last time we had a look at the Process Designer which allows us to build processes with various out-of-the-box activities. But the application I am working on requires functionality that's not available by default. This is the process I designed; I highlighted the parts that I had to  write myself:




So there's an activity called Ping which accepts a machine name as the input and returns a Boolean indicating if the machine is alive or not. Then there are two activites which retrieve version information. The ARS activity accepts the machine name and returns the AR server version (if available), the Mid-Tier component accepts the server URL and returns the Mid-Tier version (again if available). They're both fairly simple and didn't require a lot of complicated code. So let's have a look at the Ping component to see how I wrote this. Don't worry, we'll definitely have a look at some more complicated examples in future blog articles, but let's get the basics right first.


Apps written in Innovation Suite use Maven, which is essentially a build tool that helps you to manage your files, libraries, dependencies and so forth. If you want to extend your current application with new activities you can write these using Java code. The first thing you need to do is import the Maven project into an IDE, our preferred IDE is Eclipse. What you'll be writing are called Services which translate into the activities you see in Process Desiginer.


To do this you need to create two new packages which help us to order the various files we require. Think of a package as Java's equivalent to a namespace, it helps you to organise the various files and avoids name conflicts. You'll already find the package at com.bmc.bundle under src/main/java, which is created by default. This contains or depending on if you're building an application or a library. You need to create a new package, choose a name in line with your project, for example com.acme.service and put this under src/ Just right-click, choose New and Package. This is what this should look like:




Next, create your Java files under the new package. You create one new file per category. This corresponds to the categories you'd see in Process Designer (Activities, Events, etc). You can't specify the name of the category it will just take the first part of the name. I'll call mine, so the category name will be Ping.


Here are the bare bones of the component. Notice the BMC specific imports which are required. The package corresponds to the package name we set earlier and the class name of course matches the file name.



Essentially a Service is a group of methods, each of which has an input and it returns an output. That's all it is. So if you're familiar with writing Java functions this should look pretty familiar. But notice the BMC-specific Annotation which extends the normal functions to ensure it's recognised by Innovation Suite. If you want your function to show up as a service in Innovation Suite it needs to be annotated with @Action – if you leave this out it will be handled as a normal (internal) function. There's additional Annotation added to handle the input parameter: I add @ActionParameter to make sure it's recognised as an input, I also add @NotBlank and @NotNull to specify the parameter's prerequisites. But other than that, I just handle it like a normal function.


Let's go back to our example: I want to check if my machines are available or not, so I want to execute some form of ping command to check if they're alive. There's no TCP ping command in Java, but I can just use InetAddress. I'm aware this doesn't work under all circumstances, but it does the job in my internal network. I always start with a simple Java class, I want to ensure all the code works correctly before I convert it to a proper Innovation Suite service, so without any annotation. In this case I work with this example:




It's a straight forward test: if I run the class it correctly returns True if the machine exists and False if it doesn't. When all of that works fine it's time to convert it to a service. I copy the code to my new Java file and add the correct Annotations:




There are no major changes, it's just formatted in a specific way. The only thing that remains is to register the services in (or if you're building a library). I reference the libraries and register them:




And that's all you need to do. Next we need to recompile it using a Maven (mvn clean install -Pexport -Pdeploy for existing projects) and keep our fingers firmly crossed we don't end up with any weird errors. If all goes well refresh Innovation Suite and the new service should now show up in Process Designer as an activity and it's ready to be used. So let's start building those Processes and Rules and and see if it actually works!




I know my example was very simple, but you can see how easy it is to enrich the current functionality of Innovation Suite. If there's something you need for your project and it's not available out of the box, you don't have to log an enhancement request and hope for the best – you can just write it yourself. It can be as simple as a small function to ping a server or as complicated as a full integration with an external system. But the great thing is that it's completely up to you.


That's it from me, next time we're going to have a look at how to actually debug your Java service. Trust me, it's easier than you think! In the mean time, if you want to learn more about developing Java Services and want to have a look at an example which goes into more detail, be sure to check the Development Tutorial.


Until next time,


Justin Bakker