Tag: SOA

REST Primer for F&I

I have worked with more than a few APIs, both “F” and “I” – pretty much all of the product APIs, plus the original open standard for credit applications – and I write about them occasionally.  See here, here, and here.  Mostly these have been SOAP, but REST is the standard for a growing community of digital retail players.

The first thing you need to know about REST is that it’s not synonymous with JSON.  If you get this wrong, you can produce a really bad API.  I saw one once, where the developers had simply converted all their old XML payloads to JSON.  You could tell because every call was a POST, even the rate requests.

Why is JavaScript more successful on the Web than Java? It certainly isn’t because of its technical quality as a language – Roy Fielding

The key to REST, as you can read in Roy Fielding’s dissertation, is making appropriate use of the Web’s native HTTP environment.  Practically, this means knowing a little bit about HTTP and how to use its commands, URLs, parameters, and headers.  For a concise guide, see The REST API Design Handbook by George Reese.

Philosophically, it means thinking about your API in terms of resources and not services.  This is completely different from SOAP APIs, which are called web services.  For example:

  • GET rates from a product provider, but
  • POST a new contract, and then
  • PUT status codes on the contract to void or remit

Fielding’s achievement was not only to define the REST style, but to derive the style from a specific set of requirements: stateless, client-server, code on demand, etc.  If you have ever wondered why JavaScript has become so popular, it is because JavaScript satisfies the code on demand requirement.

When you build a RESTful API, you should never break existing client code. Really, never. You don’t deprecate – George Reese

The URL in a REST call looks like a path, so you can do groovy things like:

  • GET /rates/{dealer} – gets all applicable rates for this dealer
  • GET /rates/{dealer}/{product} – gets only one product
  • GET /rates/{dealer}/{product}/GOLD – gets only the Gold coverage
  • GET /text/{dealer}/{product}/GOLD – gets the rich text description for Gold

For some live examples you can run right now, check out the NHTSA Vehicle API.  It has many handy methods like:

  • /vehicles/DecodeVin/{VIN}
  • /vehicles/DecodeVinExtended/{VIN}
  • /vehicles/GetAllMakes
  • /vehicles/GetEquipmentPlantCodes/{Year}

Note that you are making the request with straight HTTP and a query string, and you can have the response as JSON, CSV, or XML.  The NHTSA site will also show you the headers, the raw data, and formatted data.  Your tax dollars at work.  You should also check out the Edmunds API, VinSolutions, and Fortellis.

  • //api.edmunds.com/api/vehicle/v2/vins/{VIN}
  • //api.vinsolutions.com/leads/id/{LeadId}
  • //api.fortellis.io/vehicles/reference/v4/vehicle-specifications/vins/{VIN}

These are all examples you can emulate if you’re just getting started.  In particular, I recommend studying how they handle authentication and versioning.  Note how they’re organized around resources and, if you have an OO mindset, think of your objects first.  You will also want to look at platform tools like Swagger and MuleSoft.

Full Lifecycle API for F&I Products

I have just wrapped up design work on a web service to cancel and refund F&I product contracts.  Whether a refund is owed to the customer, from an early termination, or to the lender as recovered funds, it is in the provider’s interest to support an efficient automated process.  On the lender side, it is also a compliance issue.

This job was rewarding for me because it completes the lifecycle I began automating, ten years ago, with electronic rating.  MenuVantage was a leader in rating and originating product contracts, and many providers adopted our model specification.

I then did related work at GMAC Insurance, which was to include claims processing.  Sadly, the crash of 2008 ended that project.  GMAC also had the bright idea to check for an earlier contract, and apply the refund to the results of the rating call.

product-lifecycle

The industry has been developing web service support piecemeal.  First, there was a need for rating and contracting, supported by companies like MenuVantage.  Now, there is financial and regulatory pressure to automate terminations, supported by companies like Express Recoveries.

In hindsight, a savvy provider would have looked at the core processes and developed web service support for the whole lifecycle.  It would look something like this:

  1. Dealer and vehicle information  Return customized rate structure
  2. Deal information with chosen rate  Originate contract
  3. Form request Return contract as PDF
  4. Form with digital signature Store in secure archive
  5. Blank form request  Return blank form
  6. Void request Void contract, if eligible
  7. Remittance query Return remittance log
  8. Remittance notify ⇒ Post pending payment
  9. In-force query Return contract data
  10. Claim diagnosis Verify coverage
  11. Claim estimate Approve/deny claim
  12. Claim entry Issue payment
  13. Vehicle data from contract Return cancellation quote
  14. Contract data plus authorization Cancel contract, issue refund

You could do one big API to manage the product from cradle to grave, and build provider portals and such on top of it.  This would have the usual benefits of decoupling the back-end from the presentation layer, and it would facilitate integration with dealer and lender software.

Providers Say No to Aggregation

My latest article is out in F&I Magazine, just in time for the VSCAC conference.  Thanks to Greg Arroyo for his fine editing.  The original “history and development of e-contracting” was not so pithy.  My thesis is that, while Dealer Track succeeded in driving dealers to a totally new process for online credit, this will not happen for F&I products.  With today’s technology, product providers do not need to participate in an aggregation portal.  Even the providers’ own portals are suboptimal, because they impose process change on the dealer.  The article gives additional reasons why providers won’t follow the Dealer Track model.

As I have written here before, the best place to present products is in a system that the dealer is already using.  Ideally, this means the DMS, but it could also include a menu or desking system.

The Portal Puzzle

Many Provider Exchange Network customers have dealer-access “portal” sites.  These sites support electronic rating, contracting, and a variety of other functions.  Providers tell us they’re happy with this approach, and what they really want is DMS integration.  We end up referring these customers to 3PA and RCI.  Along the way, we try to make the case for PEN.

As I wrote recently in P&A Magazine, the purpose of PEN is to transfer data directly between the DMS and the provider’s administrative system, bypassing any intermediate systems.  While we do support a menu system, we connect “behind” it, on the provider side.

Farsighted providers, like Safe-Guard, recognize that their portal is just one tool the dealer might use to sell F&I products.  Indeed, some providers use a web-service approach to support a portal in parallel with multiple menu systems.  Our pitch with PEN is that going direct to the DMS results in a more streamlined process for the dealer.

Efficient DSP Integration

I have just published a white paper on DSP integration for F&I providers.  This builds on an observation I made while working at GMAC Insurance last winter.  Rather than struggle with a DMS interface, providers should develop their own web services – and let the various point-of-sale systems come to them.  This is much more efficient, and good SOA practice besides.  Click here to download the paper, or visit the Virag Consulting web site.

Providers Keeping Their Forms

I have been polling my friends in the F&I Products industry, to hear their thoughts on DSP integration.  In general, they report obstacles at the dealer level and lower volumes than anticipated. The growth in web services continues, of course, with scattered outbreaks of SOA.

What I mainly wanted to hear about was forms management.  GE was the first, in my recollection, to provide completed contracts using their own web service – and this is now the trend.  It seems increasingly unlikely that providers will hand their forms over for administration by a DSP.

Reynolds Certified Interface

About a year ago, I advised GMAC Insurance to develop a service-oriented (SOA) front end, so that DSPs could integrate with them – instead of a DMS extraction approach.  This turns out to have been the right call, now that Reynolds has shut down DMS extraction.  No one I spoke to at the conference has a good solution to the new security measures.

Contact me if you need help developing a sanctioned interface.  I have a thorough understanding of the requirements, having been briefed in Dayton by Reynolds developers.