Get Escrow.OpenedDate on IOrderInfo

[JDavis]

How can we get the Escrow.OpenedDate when doing a search that returns IOrderInfo? We have searches that depend on this date and we also need to display in the UI.

[John Morris]

Are you trying to search on that field or simply return its value as a part of the results?

That date (Escrow.OpenedDate) is not a part of the order's "header" data (IOrderInfo) that is used for returning search results. This means that you will need to accomplish getting the value by alternative means.

You could opt to open the order (in read-only mode) after getting the search results, but that would most likely be too slow and create a Select 1+N performance issue. So, don't do that.

Alternatively, you can extend our worklist feature to allow for a custom worklist query source. That would allow you to have more control over what criteria is used for the query and exactly what results are returned. This isn't a trivial approach, but it is doable and supported.

Can you provide a little more context around this? How is this information used and under what use cases? That might help guide any other suggestions.

[JDavis]

John, we have an external system that creates orders (passes it to Select) and if that created order has the same TMK as an existing InProcess Select order, it is put in a holding queue. A user then goes to our screen, where they click on the order, which then does the IOrderInfo search to return the matching Select orders by TMK. They then do their research to see why these duplicate orders have been placed via two different systems. They then have the ability to cancel the duplicate order, or to allow the Select order creation. The Escow.OpenedDate is important to the user to compare the duplicate orders so they can track down why the client potentially had created/requested multiple orders for the same property.

At this point in time, we need to return the OpenedDate in the search results - yes it would probably be too slow to open each order to get it. I can imagine times where it would be helpful to search for orders by OpenDate though.

[John Morris]

TMK - What's that?

How do you find "the matching Selects order by TMK"?

If the search result list likely to be small (< 5 items), then opening an order might be possible. In read-only mode, opening an order is actually fairly quick on modern hardware (< 0.5 seconds).

You can always use direct SQL to READ data from the database. That would be the fastest way here, but that has other issues to consider.

You can add a custom endpoint service in the Select Server to handle your specific needs. That way, you can do your own SQL and keep away from violating the "no direct SQL from client tiers" rule. This would require a server-side package *and* a client-side dll to help you call that new endpoint. This endpoint would be yours alone, but it would partake in our security model and other goodies. This is an advanced topic (although less advanced than custom query list sources). It is also supported and doable. If you opted to take that path, you'd learn some good tricks about our system. It would likely require an online training session or two.

Adding this date to the built-in IOrderInfo interface isn't likely to get onto the feature list quickly. Most of our efforts are focused on the CFPB changes.

Hope that helps!

[JDavis]

John, sorry, TMK == TaxMapKey.ID

We'd be interested in whichever way you think is the best. We would like to keep using the API or SoftPro supported method as with this move to 3.0, we are trying to wean ourselfs off of going directly to the database, which we had done extensively for version 2.

Would the custom endpoint also allow us to search for the Contact.Person.Lookupcode as asked in this post viewtopic.php?f=19&t=722

[John Morris]

The Contact.Person.Lookup field is not included in our search indexes, so searching on it isn't natively supported by the app.

Writing your own server-side helper is probably the way to go here. It does use our APIs and it would also involve using SQL too. That isn't all bad. Just remember that we only support READ operations at the db level. Any WRITEs must go thru our APIs unless you're writing to your own db objects (tables).

It is likely that both those fields are not indexed by default. So you may need to add indexed views to allow for quicker search results. We prefer not to have customers add indexes directly to our tables because it can cause upgrade issues in the future. However, adding an indexed view should provide better protection from those issues.

I would recommend getting in contact with our support/sales staff and look into purchasing some dedicated API training sessions to help get you started on that path.

[JDavis]

Any way to just get a sample project with documentation on the server-side helper first?

[John Morris]

I will send you a sample I have sitting around. See if that helps. Otherwise, I suggest setting up a training session.

[kwesterlage]

I know this is resurrecting a dead thread, but we're having a similar problem.
Is this behavior still supported for the current version, and if so can we have sample code?

[BobRichards]

Sorry, but would you please start a new thread and describe exactly what you want to achieve? Thanks.