Any expericienced developer knows that best practices for programming tell us to segregate the code in three layers: Data Access, Business Logic and Presentation. Remedy developing is not programming, but the three layer paradigm can be applied too if the developer follows a set of few rules.

These rules add a series of constrains to the development, and also a little extra cost since some actions can’t be done in the easy way. But the investment will return surely in the future, because of the advantages they provide.

In this post I will review the three layers concept and how it can be applied to our beloved Remedy.

Three layers programming paradigm

The best practice is to organize the code in the next three layers:

Using this approach, you develop a data access element, that creates the SQL, connects to the database and retrieves the required data. Then you develop a business logic element that call the data access element you just created. This business logic will check and perform all the rules you program (like guarantee that the salary of an employee is not under the minimum legal salary). Finally you develop a graphical user interface (a form, a web page, …) that never calls the database or the data access objects, you just call the business logic elements, so you can be sure that the data is accessed in the right way and all the business rules are executed as planned.

The advantages of this approach are numerous. First it provide an ordered framework where a developer can organize its elements. A new developer will find easily any part of the code, assumed it is placed at the correct layer. Second, layers are easily interchangeable. The same business logic can be used for different presentation elements, so no replication of these business logic is needed. Also a change in any layer do not imply a complete recoding. For instance adding a new business rule only affect the related business rule element, and there is no need to concern about which forms or web pages are using it. Finally it can abstract the work for different professionals, where one can be specialized in business logic programming and another is an presentation expert.

Applying the three layers concept to BMC Remedy ARS

The three layers concept can’t be applied directly in our ARS developments, since there is no way to create libraries or stored functions. But, following a few rules we can find a very similar methodology using the ARS elements.

First, the data access layer, that is the generation of SQL sentences, is already present in the ARS engine. In fact the ARS engine is the data access layer. So, a first rule apply: Minimize the use of Direct SQL actions over forms. Using a direct SQL action over the data of a remedy form is to bypass the ARS data access layer. This must only be used when the data you want to retrieve is not available from ARS. So, always try to use the SET and PUSH actions, instead of sending Direct SQL actions. The data access layer design action is performed when you create fields in a form.

Second, the business logic, must be implemented using filters and escalations. That is a must. Don’t forget that business logic is the set of rules that guarantee a coherent data. If you model the business logic as filters, you are guaranteeing that these actions are always performed when accesing, modifying or deleting the data from any source, like:

Summarizing, if you force a rule using filters, this rule can’t be overridden, no matter the source of the change.

Third, the presentation layer is composed by the form views and active links. The objective of this layer is to make the most usable as possible application for the user. This can include checks, in order to prevent the user that the introduced data is wrong, but this not substitutes the filter, that must also be present.

Common mistakes

Accesing the data directly from the upper layers

As said, minimize the direct SQL actions to the indispensable situations. One of the situations that can force you to bypass the data layer is when you want to execute a query with complex aggregate, like in a unique many to many relationship (very hard to obtain from ARS).

Placing business rules at the presentation layer

It isn’t uncommon to see a senior Remedy developer to use active links to force some business rules. For instance, let’s imagine that we have a human resources application with a new hire form. This forms includes two fields, the employee category and the salary. There is a business rule that sets the salary depending of the employee category. A developer has to options, to create an active link that updates the salary each time the employee category is updated. Or he can create a filter that computes the salary on submit. The second solution is the correct.

So, what happens if we have some functionality that is both business and presentation? For instance, in the previous example there is a requisite for the client: “as soon as the employee category is selected I want to see the salary in the form”. It is a business rule, so it must be a filter. But also, is a presentation requisite, so it must be an active link. What can we do? Do both.

Yes, first you must design an active link to present the result, and next you must create a filter, is the salary is null, compute them, if not, check it to assure that the salary is correct.

Why must i reproduce the code two times since I’ve checked it using an active link? Because there are a lot of scenarios where the active link is not fired:

• The use of a join form that feeds from our form.
• The use of web services.
• The use of a bad client, (for instance an old version or corrupted one) that doesn’t fire the active link.
• The use of an evil client. You can’t control what it’s done at the client. It can be a security hole.
• The use of the API

As in a three layer design, in Remedy you must validate the data two times, first using active links at the client, and second using filters.

Placing presentation functions at the business rules layer

Sometimes can be useful to create a filter that pre-computes some value, in order to avoid computing it every time at the presentation layer. For instance, you can have the support group ID (which is the correct data) and every time you show the form, a presentation function will obtain the group name. At a first sight the correct would be to place this presentation function as active links (calling service filters), but in ARS this can have some counter effects, like it is not possible to provide a list (for instance inside a table field) with the support group name, or each time you change a register, you must compute the group name, with the performace degradation.

ARS has limitations, so sometimes is better to broke this rule. But if not try to follow it. For instace, in the previous example, if you program a filter to precompute the support group name when modifying the request, then a support group name change will not be displayed on related elements.

What does BMC?

BMC definitively don’t follow these rules. In fact I think that BMC developers are not the best example to follow. Take a look to the HPD:Help Desk form. There are a lot of business rules programmed as active links. This has lead to a lot of extra elements to be created in order to maintain the functionality. Two examples: