Using Remedy Forms as Objects

If you are a C++, .Net or Java programmer, then you surely now the advantages of object programming. When creating ARS workflow elements, you don’t have those Object. Well, you can have it if you program some app in java and integrate it in Remedy using the API. But if you restrict your code to use only filters, active link and escalation, you can’t have objects,… Isn’t it?

In this post I will show you a way of using forms, having some object programming capabilities.

What’s an object

An object is an entity that can hold data in a structured way jointly with code attached to the data. So you can have an object that holds all the information of an employee, and if you want the salary of the employee you can fire some code attached to the object that delivers the salary. This so simple definition does not cover all the capabilities of an object (like hierarchy, for instance), but it’s enough to understand the rest of the post.

My “objects” created with forms won’t have all the capabilities of an object, but a reduced set of them. But for me had meant a great advantage when developing Remedy apps.

The basis

The idea is to use a form as an object. The structured data part of the object is intrinsic to the form (a form is actually a table with an structured set of data). But the difficult part are the methods or properties. Actually both methods and properties are functions related to the object. We could create functions as I described in Functions in BMC Remedy ARS. But this kind of function doesn’t adapt well to our case. The better election is to use the service action.

The service action can be fired from active links, filters and escalations, allowing us to use the code from the server or the client. But the code will be always executed at the server. When we call a service action we can select a request (using the Request ID field (1)) an input mapping and an output mapping. The input mapping is the set of input parameters to our method or property, and the output mapping is the retrieved information.

But we can not use multiple services for one form. Continuing with the employee example, we need to create two functions: one to obtain the salary (input parameter is the month) and to add a variable income (the income and the month are the input parameter). I mean, there is no way to call service “salary” and service “add variable income”, you only call the service of the form. So we must create a way to differentiate between functions.

My approach

Here is a set of best practices I created by reviewing the way of doing of BMC’s developers and my own experience.

First, add a selection field to the form (reserve the same number for all your forms to this field):

  • Name: “Function”
  • Type: Selection Field
  • Selection values: Add one option for any function you want to create.
  • Entry mode: Display Only

If you include it in one view, set it to not visible.

This field will tell the form which function is called.

For each function create a guide, this will allow you to easily track the filters associated with each function. Include in the guide all the workflow you need to obtain the output data or to execute desired actions. The filters included in the guide must all have no execution options (that is to execute only when called from the guide).

Then create a filter for each funtion with:

  • Execution Options: Only “service”.
  • Qualification: $Function$ = <name of the function>
  • If Actions: Only one: a call guide to the related guide.

To summarize, when a service is called, we must add the Function field and set it to the name of the function we want to fire. Then all the service filters will check the name of the function and only one will call the correct guide.

Best practices

There are some situations that must avoided:

  • Don’t share filters between different functions. I would recommend you to duplicate the filter.
  • Don’t use filters for sumbit, modify, delelete or any other action in the guides.
  • The fields created to input and output mappings can be shared between functions. But take care of share these fields with non-service activity.
  • The fields created to input and output mappings are normally set to display only.
  • Don’t create service actions for simple set actions. Only to complex set actions with logic. For instance in our case

The function field

My recommendation is to use a selection field to hold the function name. But BMC’s developers normally use a text field. My rationale to use a selection field is:

  • The likelihood of error when writting the name of the funciton is reduced.
  • The list of available funtions per form is easily accesible.


Like in objects, you can call a service and the code will depend on the called form. For instance, you can have a lot of form with a method “Erase”. This method will delete the request and perform all rules to ensure data integrity. So it can be that from a form you call the “Erase” method of a form giving the name of the form in runtime, so the executed code will depend on the form.

Posted on by Jose Huerta in Best practices, Developing solutions

About Jose Huerta

Jose is a project manager and service manager from Mallorca (Spain). The last years, he has been closely related to Remedy at almost all levels: deployment, customization, consulting, administration and service management. His work doesn't end with BMC products, but he's continually exploring other aspects of IT management, as the leader of development projects and IT services.

3 Responses to Using Remedy Forms as Objects

  1. tom

    Does anyone know why the Activity form is to big when using Win 7. the icon to bring up the whole lising of the Activity are gone….. please assist if you know a trick to fix this

  2. Pingback: The Service Action | The Remedy for IT

Add a Comment