When applying a templete in SoftPro Select, an Apply Template Failed error appears showing a couple Infinite loop detected errors. This can be caused by quite literally just about anything. It is coming from either a formula or Iron Python rule attempting to access a part of the file that doesn't quite exist yet.
Attempting to save the file at this point can result in a "Violation of PRIMARY KEY constraint" in "some multiple table" complaining about a "duplicate key". Sadly that error doesn't help find where the Infinite loop detected happened. I've seen it close, but never on the mark. This error can get quite long, but remains repetitive with each Violation having a corresponding terminated . The program error log can be helpful, <ctrl><shift><L> prior to the error.
What causes it
Let's start with a bit of what is happening when an Apply Template is used. As Select is creating the file, it doesn't necessarily happen in a direct chain of events. The file is being built very fast in pieces, if part "A" attempts to use part "B" before part "B" exists, life can be very bad for the file.
That minor error blows the whole overlay up, and we want it to. Remember Select is transactional in nature, it won't process any part of an event unless all parts of the event succeed. Everything has a pass fail check on it. That important concept is why a partial file isn't created. Somewhat a side effect is that nature also raises the complexity, making generating useful errors more difficult. The piece of code which figures out there's a problem, is quite far away from where on the users interface the problem originated. This is part of the reason we see these imprecise errors in different places. Hats off to the dev team though, we've seen appreciated improvement in the last couple revisions, go dev go.
Check before you set
When creating Iron Python formulas, you learn very quickly to check for nulls. It's the usual development process to make sure you have something, before you do something with it. I suppose that's useful in the real world too, there's no reason to swing a bat if you're not holding a bat. In the Apply Template case, things are happening in parallel, but still have to work, so null checking becomes more important. Select formulas come into play when direct index calls are made.
Imagine this simple formula on a Lender Contact Proposed insured clause: field
{{Order.Title.LoanPolicies[1].ProposedInsured}}
It works just fine during testing and initial roll out. Select knows during the processing of the file to not put anything in the field if a LoanPolicy doesn’t exist. Apply Template is FAST, you might not think of it that way, but trust me, it's blazingly fast for what it's doing. I don't think the same rules that exist in the user interface are fully in play. Depending on the data, the Lender Contact can come into a file either before the LoanPolicy, or without a LoanPolicy and cause a formula like this to stop the process.
How to prevent it.
Check to see you actually have something before doing any direct index calls. You might even need to check your something really has a parent something. You may be thinking, What was that again.
Let's change our code as an example.
If (Not IsEmpty({{Order.Title.LoanPolicies[1].ProposedInsured}})) Then
{{Order.Title.LoanPolicies[1].ProposedInsured}}
EndIf
Now we seem to be checking to make sure the ProposedInsured actually exists, so the problem will be fixed.
It's not.
The problem here is there isn't a LoanPolicy when the error is generated. We're asking for LoanPolicy[1] or the first loan policy. If there isn't one, an error is generated before .ProposedInsured is looked at. Putting that hard coded number 1 in there is the root cause.
Working Example
If ({{Order.Title.LoanPolicies.Count}} > 0) Then
{{Order.Title.LoanPolicies[1].ProposedInsured}}
EndIf
Is there another way?
There is always another way. For this sort of thing I'd consider using a foreach or Iterate Loop, and process only the first one. The foreach by nature will be able to deal with the null reference when no Loan Policy exists. Plus it's nice to know what .Count is, but it's way more useful to know how to Iterate.
That looks like this:
Iterate {{order.Title.LoanPolicies}} From 1 To 1
{{Order.Title.LoanPolicies[1].ProposedInsured}}
Loop
So we're saying, Hey Select, if you have any LoanPolicies hanging about, start at the first one, and do one of them. Note: if Title were a multiple, it would be possible for this to fail when there were no Title's on the file, so check the parent when necessary.
Another iteration that works is a little more verbose, thus more educational.
Iterate {{order.Title.LoanPolicies}} From 1 To # {{order.Title.LoanPolicies}}
{{Order.Title.LoanPolicies[1].ProposedInsured}}
Break
Loop
So here we're saying loop through all of the LoanPolicies if any exist, but quit (break) after the first one is processed.
A little better
Finally to cross a t or dot the i, we make sure we actually have a value before attempting to use it.
Iterate {{order.Title.LoanPolicies}} From 1 To #{{order.Title.LoanPolicies}}
If (Not IsEmpty({{Order.Title.LoanPolicies[1].ProposedInsured}})) Then
{{Order.Title.LoanPolicies[1].ProposedInsured}}
EndIf
Break
Loop
As it goes, there's another good way.
If ( Not IsEmpty ({{Order.Title.LoanPolicies}})) Then
{{Order.Title.LoanPolicies[1].ProposedInsured}}
Endif
This is a good example of checking the existence of something before using it. It is also how parent and grandparent items can be checked for null.
The moral of the story is a single line formula that contains a hard index is a potential problem. It will work some of the time, it won't for Policies and other unknown areas. So be safe, do some checking to make sure things actually exist.
A quick note, I'm not using value= syntax in this example you probably should, so the active line would be
value = {{Order.Title.LoanPolicies[1].ProposedInsured}}
How to fix it
Search the formulas for [1], any one of them could be the problem with some noted exceptions. Create a SoftPro support ticket to see all your formulas in one text file. All Orders have a base set of multiples that would never cause this problem. Order.Properties is one of them. All Select Order dot based "files" always have a property multiple. I think there are a couple more, if you have that list, send it to dan@vfinfo.com, or better yet, post a comment.
I now have 130 contacts in this test file, anyone want to delete them? A special thanks to Kayla who assisted in figuring out what was causing the initial error that lead to this blog entry. I don't typically blog on support assisted fixes, in this case the value of understanding that formulas are more complex than they may appear, was worth bending that rule.
