Throughout our years of Kronos Consulting, we’ve seen some pretty complicated Workforce Integration Manger (WIM) interfaces. I’m talking interfaces with 50+ links in them and each of those having dozens of formulas, each one reading or writing a temporary file to work on data! Do you know what I’m talking about? Have you ever tried to come in afterward and support one of those interfaces. It can be pretty difficult. They are the kind of interfaces where if you fix one thing, you tend to break many others!
Kronos has employed us numerous times to come in and figure out what other people designed and simplify the process. We’ve developed a pretty straight forward method of doing this. Here are some tips on how we go about doing this.
Tip#1: WIM is a very effective data mapping tool, use it only to do that.
I find that WIM is generally overused to perform complex calculations. It is capable of doing this if you know the in’s and out’s of WIM, however the problem is that it’s not a programming language! Getting the complete picture of all the calculations by summarizing hundreds of variables across dozens of links isn’t feasible. So this is what I recommend:
Keep your interfaces straight forward and limit them to the following functions:
- Use WIM to import or export data to/from a flat file to the database.
- Use WIM to import data into the Kronos APIs.
- Use WIM to wrap functional calls to your database components.
This limits your programming in WIM and keeps the interfaces straightforward and maintainable. So the next question is this “Ok… If I’m not putting my business logic in WIM any more, then where does it go?” That leads me to tip #2.
Tip#2: Implement Complex Business Logic and Data Structuring in your Database Objects
There are a number of reasons to put your business logic in SQL. Here are a few. (Keep in mind this is the tip of the iceberg!)
- SQL skills are a lot easier to find on the market than people who know WIM. This simplifies your support after your original developer has left the team and moved on.
- SQL is also an inline, straightforward language. It makes writing complex business logic and scenarios easier than in WIM. A good SQL developer can normally get the complete picture of the logic by reading a SQL file.
- SQL allows you to comment your code! WIM doesn’t. This is invaluable when trying to figure out why something was done a specific way.
- Performance: You can control and tune performance of a stored procedure much more easily than WIM. Implementing logic there allows you to leverage true programming constructs of variables, arrays, cursors, tables and other items and eliminate round-tripping between the OS, application server and database. It also allows you to deconstruct queries to gain performance without major coding efforts.
So how do you put these to work? Let’s follow a straight forward example:
A Simplified WIM Example
A weighted overtime interface can be a complex scenario requiring a large WIM interface to perform these calculations, correct? Not really if you follow the tips. When we first inherited this interfere, there were 12 links that created and read multiple text files to stage, process and calculate temporary data. This is a necessary evil when performing complex calculations in WIM.
The customer was trying to fix what they thought was a straightforward problem that “never worked correctly” in the first place. We were asked to help and came up with a new approach that was coded and delivered in only a few weeks. Here’s what we did:
- Developed a single WIM interface with a single WIM link.
- The WIM link called a stored procedure in a pre-process variable in WIM. The stored procedure did the following:
- Identified employees who qualify for Weighted Overtime.
- Calculated the employees Weighted OT adjustments and stored the data to a temporary table.
- Calculated what values were already on the time card, and updated the temporary data removing time that was already paid.
- Determined if approvals/signoffs had already been applied to the affected employees time card. If the approvals/signoffs needed to be removed the stored procedure added an entry to the same temporary table to indicate this.
- The WIM link then read the temporary table as a source using a simple select statement. It mapped the query results to either the Paycode Edit API (Add/Delete) or the Signoff (Add/Remove) APIs in the correct order to fix the employees time card.
In the end, this improved performance from a run time of over 10 minutes to a run time under a minute, and it established a new platform for the interface that the customer’s DBA could maintain themselves. Oh… by the way we were also able to solve the original problem they were trying to fix!
If you’d like to found out more let us know! http://www.delaero.com/contact-us