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