Infor Public Sector / Hansen is a powerhouse that can support just about any public sector business process you can imagine because it is so highly configurable (read more about IPS configurations in another of our other articles). This configurability comes with some risks though, as poor custom workflow and formula logic within the system can cause serious performance issues.
The intent of this article is to cover a few of the more common configuration and workflow performance issues that we’ve seen. Hopefully this will help you identify some of the issues your IPS system might be experiencing, so you can formulate a plan to implement (hopefully simple) logic updates to make noticeable improvements to your system’s performance.
While your system’s configuration may be the cause of some of your performance issues, as you read through this article, please keep in mind that environmental, data, or other factors could also be the cause.
Inefficient Workflow Formulas
Infor Public Sector contains a powerful workflow engine with a number of events that can be used to execute logic. This logic can do anything from simple form validations, to sending an email, to reaching out to other enterprise applications. The more logic you add to these events, the more work your system will have to do with the click of any button. That is why it is important to avoid the following common mistakes in your workflow formulas:
Multiple Database Round Trips
Infor Public Sector / Hansen calling out to the database to retrieve data is one of the slowest actions that can be executed, so it is obviously important to minimize the number of times this occurs. We have seen workflow formulas making a large number of unnecessary database calls (sometimes even within a loop), contributing to serious performance issues. If you don’t have a background in development, some of these may be harder to spot, but if you are reviewing a formula and you see data being loaded, ask yourself if it is really necessary. And if you see a database call within a loop, try to find another way to retrieve the data you need in a single call before the loop.
Calls to External Systems
We’ve already mentioned that a round trip to the database is one of the slowest actions that can be performed. Synchronous, real-time calls to external systems are another one.
Sometimes these external service calls are unavoidable, such as a call to your GIS system to validate an Address before allowing it to be added to your system. At other times, you might not require that immediate feedback, and in these instances you should consider an asynchronous approach to external service calls. You can accomplish this using a queuing technique backed with a scheduled batch task, configured in Infor Public Sector’s Batch Manager.
For example, let’s say you are creating a work order or a service request in a separate system when a permit application reaches a specific milestone. Instead of making a real-time, synchronous call to that separate work order / SR system, insert the request into a queue table in Infor Public Sector / Hansen and have a separate batch process running, querying the queue every so often and sending data to the other system. Now when a user clicks a button that results in a permit entering that specific milestone, all they have to wait for is a single record being written to a queue table (fast), rather than a system-to-system communication taking place to create a work order or SR in another system (slow).
Loading Too Much Data into Memory
Querying for too much data can impact performance in a number of ways. A larger number of records will consume more bandwidth and take longer to return from the database. It will also consume more application memory, and if your server(s) run out of memory that will have a huge detrimental impact on performance. Also, any logic written that iterates through all of the records will take longer to execute.
The bottom line is if you need to read data from the database in your workflow formulas, be careful about the number of records you are returning. Use as many WHERE clauses as you can to trim the data down at the database level and only return the records you absolutely need. Databases are extremely efficient when it comes to filtering and ordering records, far more so than any web application such as Infor Public Sector, so it is always a good idea to let the database do the heavy lifting.
Writing Too Many Separate Formulas
It is possible to add many formulas to any event in Infor Public Sector / Hansen, and as mentioned, these formulas can perform many different actions. Sometimes it makes sense to break these formulas out into individual actions, and other times it might be beneficial to combine them.
It becomes especially beneficial to combine workflow formulas when separate formulas are executed on the same event of a business object (BeforeUpdate, AfterAdd, etc.), and they make the same calls to the database to retrieve the same data.
Note that we are not advocating a single formula for each event, as that would lead to a confusing workflow configuration that would be challenging to maintain. This is just a suggestion to consider combining formulas when it makes sense, and when it may help your system run more efficiently.
Missing Database Indexes
If you have custom schema and business objects in your Infor Public Sector / Hansen system, such as custom Detail Pages and Grids, check that the relationships between those objects and any related objects (such as Code Definitions) have been defined correctly in Infor Public Sector’s Schema Manager. When these are not defined, the system will not know to create indexes on the appropriate columns in the database. This can really hurt read performance, especially as the record count in those tables and their related tables grows.
Auditing Everything
Storing historical data is useful for many reasons, and sometimes it’s even legally required. Infor Public Sector provides basic auditing functionality and it is up to you to decide which objects / tables you wish to audit. Keep in mind that enabling auditing does have a negative effect on system performance. The more entities you audit, the slower the system will become.
By enabling auditing, every time you create or update a record, an additional record will need to be written to the two tables that are used to store Infor Public Sector’s audit information. That means one database execution becomes three. Now consider a scenario where an action such as approving a Review moves an Application to its next milestone and creates a Fee. Instead of three actions (Review update, Application update, Fee creation), you have nine actions (the three mentioned plus the two audit record creations for each).
Summary
These are just a few of the configuration and workflow issues that may be causing performance issues in your Infor Public Sector (IPS) / Hansen system. We’ve seen just about everything you can imagine, but I am sure there are more inventive ways to kill performance that we’ll discover in the future. Our hope is you’ll be able to read this article and improve your system’s performance noticeably with just a few simple changes. As always, if we can help in any way, please feel free to reach out! Thanks, and good luck!
Where to Now?
Read our Introduction to Infor Public Sector / Hansen CDR Configurations
