AB Suite Application Performance Tuning

It’s never good news to hear one of your applications is experiencing a performance problem. Though you certainly recognize the importance of fixing it, knowing where to start isn’t always easy.

With help from some Unisys UK technical specialists, we’ve outlined a general approach that should help you identify, fix, and avoid these issues in your environment:

1. Set a performance target
2. Identify the problem area
3. Analyze the code
4. Implement the code changes
5. Test and repeat

Set a Performance Target

This is a critical first step – even though it’s often an afterthought, or worse yet, not clearly defined. This lack of clarity typically stems from an imprecise problem definition, such as “XYZ report needs to run faster.” That’s why it’s important to request a more clearly defined target, such as “XYZ report needs to run against the Month End in less than four hours.”

Though it may sound simple, setting a clearly defined, measurable goal will make it easier to determine when your work is done.

Identify the Problem Area

With a clearly defined target, the next step is to discover the source of the problem. When trying to identify a problem’s source, start with some simple questions:

• When did this problem start?
• Has it been getting worse over time, or did it start after a particular release or feature was introduced?
• Has anything else – IC level, new patch, MCP update – changed?

Pausing to consider these questions often gives you an idea where to start your investigation.

Assuming the source of the issue isn’t related to something like a new piece of code, how do we work out what’s causing poor performance? You could try to find the answer by adding trace or diagnostic code to the LDL+ code. While this may help, doing this for a large report or piece of the system that includes many methods can be difficult and time consuming.

This is where Unisys can help. Working with clients on several recent engagements has allowed us to identify some alternative approaches.

In the ClearPath® MCP environment, we’ve developed a process that allows you to gather statistics about the code execution. You can implement it without introducing any LDL+ changes, and easily enable and disable it as required. The output shows which modules and areas of code are used, as well as the frequency of their use.

If you use AB Suite on Microsoft® Windows®, and therefore utilize Microsoft .NET for the generated runtime code, you’ll be able to employ standard Microsoft instrumentation capabilities, such as the Microsoft .NET profiler. With these capabilities, you can see which parts of the compiled code have been accessed. Although this will not directly relate to objects at the LDL+ level, Unisys has developed an approach that allows us to correlate the output so you can see which methods, Ispecs, and attributes have been accessed.

While each of these approaches are relatively simple, the real skill lies in analyzing the results. In both cases, we recommend engaging with Unisys consultants to take advantage of the knowledge we’ve gained from multiple client engagements.

Analyze the Code

Now that you have some idea of where the problem is, the next step is to analyze the code. One option is to go into the Agile Business Suite (AB Suite®) environment and look at the code. An experienced developer may be able to identify the problem code using the information gathered in the previous step.

However, this is another area where Unisys experience may help. Our UK team developed a powerful query tool called Model Analysis Tool for Research, Investigation, and XREF (MATRIX). An enhanced version of the XREF utility, MATRIX provides query capabilities beyond those in AB Suite Developer. Some key capabilities in the current MATRIX 2.0 version include:

• Method logic flow, which allows you to create a simplified view of the logic showing just method calls, conditional statements, and loops
• Compound searches – and, or, not, starts with, does not start with
• Automatic “where type” and “where name” inheritance usage displays
• Find all statements that update or read a particular Structure
• Find all attributes that have a particular definition
• Find usage of an attribute globally or within a method, report, or Ispec
• Export results to tables and CSV files

Implement the Code Changes

The next step is to implement the required code changes. If these changes only affect a few areas, this can be done via the normal development process. However, if the code changes are much wider in nature, then it may be worth enlisting Unisys assistance.

The pModel capability in AB Suite lets you extract LDL+ logic and definitions in plain text, and can be used to automate code changes. This automation could be as simple as just renaming a field and its references throughout the source. Or, it could be more complex – something like including a reference to a new method or inserting a new piece of LDL+ code into every report.

As part of a recent client engagement, we developed a custom tool to automate changes to the pModel export file. While the tool was specific to this particular engagement, we could easily adapt it to other scenarios.

Test and Repeat

The final step is to test the changes to confirm the performance goal has been reached. If you don’t see the desired results, go back to step one and look for further areas to improve until you reach your goal.

What’s Next?

If you’re eager to learn more about anything discussed above, we encourage you to engage with Unisys for a pilot project. For further information, please contact your local Unisys representative or reach out to one of this article’s contributors directly by emailing:
gary.j.taylor@unisys.com, andy.wardle@unisys.com, or nigel.tunnicliffe@unisys.com.

Special thanks to Unisys UK System Architects Gary Taylor, Andy Wardle, and Nigel Tunnicliffe for drawing on their many combined years of experience with LINC, EAE, AB Suite, and associated products to create this article.

Share this article: