Skip navigation

Developer Community

3 Posts authored by: Justin Bakker
Share This:

Innovation Suite offers a different approach to application development, but as it’s grounded in the same principles as Remedy a lot of the traditional Remedy components and naming conventions translate quite well. Rules are similar to Filters, Escalations are now called Timed Rules, which makes a lot more sense anyway. Processes are a different beast altogether, but once you get your head around it, you’ll get it. Records, absolutely. Views, Named Lists, totally get it. But wait, where are my Active Links? What happened to them?


I’m sure you’ve written your fair share of Active Links. They make your application interactive: they handle events, respond to button clicks, execute when forms open, run when you perform a search. That’s how you get applications to interact with the end users. Dynamic behaviour is an integral part of application design. Your business processes form the engine of the application, but end-users care about the UI – this needs to be intuitive and easy to interact with. As developers we need to consider how data is presented and how users can interact with the application.


Good application design involves caring how you interact with the end user, this goes further than just buttons and tables, just think about the apps available on your phone; consider how you manage your photos, your bank account or even how you train for the marathon. A lot of user interfaces are very intuitive and with the right design make it lot easier for end users to use the applications.


With classic Remedy almost all of interactivity is done using Active Links, which is a proprietary scripting-like technique. It does two things: sometimes it is used for business logic (validation, calculating something, integrating data, etc), but mostly it is used for screen interactivity. Active Links are easy to write with Developer Studio, but the technique has its limitations: there’s a specific set of functions and you can’t go beyond that. This limits your options to control the dynamic elements of your application. You can display a table field, control what happens when you click on the entries, but if there’s anything specific you want, that’s simply not possible. It can’t be extended.


With Innovation Suite there is a different approach, you don’t design Active Links anymore. So how do you design dynamic behaviour? There’s no easy answer to this, there’s no one-to-one translation for this one. The UI in Developer Studio is made out of views which are made up of view components. These should have the most important interaction patterns baked into them – they are part of the components. These contain all the necessary code that make the interactivity possible and you don’t have to worry about this. Interaction can be done via the component’s available configuration. For example, you can configure the navigation between top-level views via the shell or filter the data in a grid based on the input of data fields. By configuring the view component you determine the dynamic behaviour. For example, this Record Grid uses an expression which is based on the values of Text Fields. I link them together via the Expression field and the records in the Record Grid change as I type. I don't have to write any code for this, all that behaviour is baked into the component and I simply take advantage of the available configuration.



That should take care of the majority of the behaviour you need to build applications, as new components are made available you can extend the application by simply adding them to the view and configuring them.


If you require more advanced behaviour you can use different Actions (out-of-the-box and custom ones) and string these together to create various effects (similar to the way you'd use Active Links). That’s all very well, but what can you do if the behaviour you want is not available? Innovation Suite allows you to extend the application by introducing custom actions and custom view components.


Custom actions are used when you need to execute custom code on an event. For example if you have rows in a record grid you can add buttons that do something with the selected rows: open the record, delete them, etc. But you can add your own actions here as well. So if you need to change the value of a few fields with a specific patters, you can write your own custom action.


If you want to take it a step further can you can write your own custom view components and bake in the behaviour you need. Like the out-of-the-box components you can use configuration parameters to interact with the system and link them to existing out-of-the-box components. You’ve got a lot of flexibility here and as you’re writing the components yourself you’re only limited by your imagination (and of course coding skills). A good example of this is the way you can present data. Consider this record grid which lists customers who escalated their support cases. Click on it and you see the escalation details.




This is all put together with out-of-the-box components. You recognise the record grid, the views, the buttons. It works well, but I want a different way fur users to interact with the data. That wasn’t available out-of-the-box so I wrote it myself. This is what I came up with:






Same data, different way of displaying this. How I wrote this is too long to explain, but it’s mainly AngularJS code. I made sure I made configuration items available which allowed me to link it to existing out-of-the-box components, in this case the selection fields:




So all my interactivity here comes in the form of the AngularJS code I wrote as part of that view component, it’s baked in, when I use it in Innovation Studio I don’t have to worry about it.


Going back to the original question, what happens to my Active Links, the answer I heard a few times is that Active Links are now replaced by AngularJS. But I don’t think that’s the right answer, it assumes that you have to code all your dynamic behaviour in Angular, and that’s not true. Yes, you can extend and if you build your own View Components you need be pretty familiar with coding. But that’s the not the place to start, dynamic behaviour is part of the components and by configuring them, by linking them together you create an interactive UI. But if you want to write your own fancy components, build on the principles of Innovation Suite, you are of course more than welcome.


Best wishes,


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

Share This:

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:




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:




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:




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:




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.




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:




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:




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:




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:




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:




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