Skip navigation
Share:|

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:

 

extending1.png

 

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 MyApplication.java or MyLibrary.java 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/main.java. Just right-click, choose New and Package. This is what this should look like:

 

extending2.png

 

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 PingService.java, 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.

 

extending3.png

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:

 

extending4.png

 

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:

 

extending5.png

 

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

 

extending7.png

 

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!

 

extending8.png

 

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

Share:|

Come check out what we built at London BMC Exchange in the KTSL booth, Thursday, November 10!

house 2.JPG

Whilst sitting in the US Engage conference talk about Innovation Suite and after using the initial BETA it occurred to me immediately how well this new technology fitted what we have been doing at KTSL over the last 2 years.  Namely extending the BMC platform to be able to take advantage of the visual and integration components available within Java and outside of the Remedy toolset.  We approached BMC and working with BMC came up with the idea of hosting a UK Innovator House similar the to one held in the US but this time with customers present and with a fixed requirement from those customers.  From this, the idea of the UK Innovation House came to fruition. 

The house was hosted over 3 days in the Surrey Hills in a quiet country location with a house able to sleep all of the required participants.  The customers were chosen because they too have had a similar vision to extend the platform and one of the customers, Unilever, have actively been extending and laying HTML 5 User Interfaces over Remedy already.  Unilever and IBM attended the house, with Unilever providing a Systems Developer and a Solutions Analyst.  IBM sent a Systems Developer.  KTSL sent 3 Systems Developers and they all worked with 2 BMC representatives and a member of the US house.

The solutions analyst at the house outlined the business process and the requirement. Simply they have multiple alert systems and they wanted one view of this external data from the Operations Bridge. Alerts marked as ‘down’ need to cut Incidents straight away but other alerts which could be an Incident need a manual verification.  The requirement was to allow the Operations Bridge one view and a quick way of creating the Incident or ignoring the alert.  This was done based on the severity of the alert.

 

The application was ideal as a showcase because we needed integrations into the underlying alerting tool (in this case Omnibus) and we also wanted links to the CMDB models.  We used the development capabilities to not only use direct REST Webservices to get the data but use a table and a graphical javascript display for the graphical element.  The suite allowed us to build something quickly which would have needed extensive customisation previously.

 

The real plus points of the suite were the speed and the scalability of it and allowing both the developers but also the solutions analyst to play a key role in the development.  It also allows you to develop additional features yourself and really make use of industry standard user interface techniques alongside the integration capabilities of the BMC technology stack.  Longer term, taking this as a base and extending it into the BMC Panama application as well building up a set of core components for the Suite will make this a industry leading and powerful development platform.

 

The house was a perfect location for the developers to thrive, with the constant interaction and the focused goal giving a much better opportunity than a training course or a Q & A session.  By working through the requirements it really gave a focus to not just 'learning' the tool but 'using' the tool which is much more valuable.  From a KTSL perspective we intend to leverage this by building applications both with our customers but also for ourselves over the coming months.  Allowing us to leverage our work over the last 2 years but now inside the Suite.  Using Innovation Suite will become a core part of the KTSL technology products alongside other exciting new technologies we intend to invest in over the next year.

 

Aaron Perrott

KTSL Head of Technology

 

 

 

Mark Robinson

 

Save

Share:|

Innovation Suite Graphic.JPG

Please join Robert Curlee, Principal Product Manager and Alex Henson, Principal Solutions Marketing Manager, as they introduce BMC Innovation Suite. Innovation Suite is new platform that empowers developers and business users to co-create powerful enterprise apps with stunning user experiences. The highly scalable platform combines the flexibility of modern coding languages with the ease of drag-and-drop designers to enable coders and non-coders to innovate together.

 

In this webinar we will introduce you to a brand new method for co-creating enterprise applications with key insights from BMC Product Managers and developers involved in the Innovation Suite early access program.

 

Event Registration Details

 

Date and time: Wednesday, December 7, 2016 8:00 am

Pacific Standard Time (San Francisco, GMT-08:00)

Duration: 1 hour 30 minutes

Registration Link: https://bmcsoftware.webex.com/bmcsoftware/onstage/g.php?MTID=e7bd83198fdf9f71edfad62d6f48b44a3

Registration Password: bmc

 

After registration, you will receive a confirmation email.

 

If you haven't done so, join our Developer Program developer.bmc.com to get access to BMC Innovation Suite!

Vidhya Srinivasan May Bakken

 

Question about this webinar? Contact developer@bmc.com

 

RECORDING: BMC Innovation Suite Launch Webinar Recording

Save

Share:|

Innovation Suite is going to be different, quite different indeed. Brace yourself to be introduced to a whole new way of designing applications, which also comes with a new array of terminology. Soon you won’t be talking about Active Links, Filters or Forms anymore. BMC Support won’t be asking you for the workflow logs anymore and we promise we won’t be advising you to flush the Mid-Tier cache every time. Instead watercooler talk will revolve around a discussion about Maven Archetypes, Record Definitions, View Components, and most of all Processes. Intrigued to learn more? Let’s go!

 

It’s the new Process Designer that will provide the engine of your new application. This is where we will write those complicated business processes in an easily understandable and manageable way. Because that’s what’s always been at the core of Remedy’s application design: you can design complicated applications in an easy way. And the new Process Designer will certainly make your life a lot easier.

 

It’s tempting to try translating traditional Remedy components one to one to Innovation Suite components. But this doesn’t always work that well. Yes, it’s similar to server workflow, but it’s a different approach. You describe a business process by defining a set of steps to achieve a goal. That could be anything from onboarding a new employee or approving a server change to placing a new holiday request.

 

I know, it all sounds a bit, well, vague. So let’s have a look at a real example. To make it more interesting, let’s compare how we’d resolve the same problem without a Process. I am working on an application which periodically needs to check a list of machine entries to check if they’re still available and if not to check if they need to be retired. I also want to update the version information and even inform the machine’s owner if the machine hasn’t been seen for a while. So we have quite a list of things the application needs to do in sequence. How would I go about implementing this?

 

Well, I’m glad you asked. Let’s try resolving this via Rules first. Yes, Rules do translate to Filters and Escalations quite well and you could use them in the same way. I have a record definition with all my data (think forms in Remedy) which looks as follows:

 

process1.png

 

The first thing I need to do is check if every machine in this record definition is still valid. I use a custom component which accepts the machine name and outputs a Boolean (true or false). First we need an escalation, sorry I mean Timed Rule (I’m getting used to the new lingo as well) which updates a hidden field called Ping:

 

process2.png

 

So all the records now have a value in the field Ping of either True or False. The update will be interpreted as a change event, so next I use another Rule which executes when a change occurs and updates the version information. This uses a Set Field action:

 

process3.png

 

Never mind the first two version components, they're custom built as well. We'll discuss how to do this in a later blog article. In addition I need a Rule that also runs on change with a later execution order which checks if the machine is expired or not. But I need even more Rules to handle the various other bits and pieces. So I need at least five different Rules plus hidden fields to make this work – it's suddenly getting really complicated. Yes, it will do the job and if you’re familiar with workflow design you can follow it, but it’s not easy to manage. If you want to change anything you need to make sure you’ve got everything documented in detail or else it’s a matter of working it out using the logs. Not ideal.

 

So is there a better way? As a matter of fact there is: you can define a Process to handle the whole transaction. It requires a different way of thinking about it. Rather than trying to resolve a problem with a series of workflow entries you think of it as an actual process. And I don’t mean designing it on paper before translating it to a series of components, I mean actually designing it as a process.

 

Let’s go back to my specification. So we check a series of machines and for each machine we go through a series of steps: check if it still exists, if so check if the versions are up to date. If not, check if the machine can be retired. So for each machine I’d expect it to go through this series of steps:

 

process4.png

 

That's of course still conceptual and the challenge is to get this flowchart translated to something that actually works. And that's a lot easier that you'd think – all I have to do is translate this flowchart to a Process in Process Designer. Let's give it a go. Processes don’t have a trigger, that comes later. Instead we define an input parameter first – after all we need to store our data somewhere.

 

process5.png

 

I use my parameter to store the record retrieved from Record Definition. Next I build the Process itself. I don't worry too much about passing data between the components at this stage, I just want to get the basics right. This is what I came up with:

 

process6.png

 

Pretty neat looking isn't it? It does the same thing as the Rules we looked at earlier but it's a lot easier to understand what it's doing. If you compare it to the flowchart I initially wrote, it translates very well. I use a few custom components like the Ping and the Version Information, but the rest is all out-of-the-box. Check the Retire machine component for example. It's an Update Record action; the Update machine details is similar.

 

I used Gateways to make decisions based on the outcome of the preceding component. So I first ping the machine and a Boolean is returned. I use the Gateway to check if this outcome is True or False. The link between the Gateway and the next components has a condition:

 

process10.png

 

That's how I work out what route is taken based on the decisions. Next I provide the various components with the data. Remember we defined the parameter? I use this for most of the components, here's Ping for example:

 

process8.png

 

It's the same for the other components. So I either use the output of a component (like the Gateway) or from the initial parameter (like the Ping component).

 

Assuming everything works okay I can now execute my Process. I want to test it first via the Manage Processes option, any problems I might have should show up here:

 

process12.png

 

All that's left to do is hook it up to a Rule and execute it!

 

Processes allow you to quickly construct complicated business functionality. They're easy to manage and it's easy see what they're doing. I don’t have to spend a lot of time working out what does what, it’s all pretty obvious. A few weeks after I wrote the initial Process I had to change it to account for machines that never were seen online. I simply added a few extra steps and it was picked up:

 

process14.png

 

See, what I mean? It takes a little while to get your head around it, but once you do Process Designer offers a powerful way to design and define your business logic. And what to you do when the functionality you need is not available? Well, you write it yourself of course – this is Innovation Suite after all. You can extend it if required. And how do you do this? Well, you have to read my next blog article.

 

Until next time,

 

Justin Bakker