At the end of this article we will discuss a summary of the different challenges that await anyone considering integrating Salesforce with their Oracle Intelligent Advisor. Many of these points are part of the analysis of any Connector project. There are essentially three or four possible approaches – “do it yourself in code”, buy an integration server of one sort or another and do it there, or opt for a SaaS solution.
You might be in the process of thinking about how to go about this job of comparing the options, so here are some key areas to consider from a product, resources and cost standpoints and there is a helpful Comparison Matrix at the end of the article.
When you consider integrating Oracle Intelligent Advisor and Salesforce, there are several product areas that can cause issues from the point of view that they are more complex or costly to implement. Each of them, when handled ineffectively, will add costs, lessen flexibility (the connector stops being a build-once use many times and becomes a one-time solution that has to be replicated for each new scenario) and increase risks (performance drops, training costs to adapt to a new way of working and so on). Read on for more details.
- ExecuteQuery
The ability to load data on the fly into your interview at first sounds simple. The input and output structures look kind of similar to those you would see in Load for example. But upon further reflection, the big issue is that fact that the syntax for the operators (and, or, not and so on) is hard to master in a way that is reusable. This is something that we’ve seen on several projects. Attempts to create a generic ExecuteQuery handler fail and the project resorts to hard-coding the query directly in the integration and not in Oracle Policy Modeling. The benefit of being able to write conditions in Oracle Policy Modeling is therefore lost. The Sofia Connector handles all the operators and functions and supports the same nested conditions as the API.
2. Attachments
A very common stumbling block – not so much from the perspective of handling them – Base64 is straightforward – but the concept of making the solution as reusable as possible. We have seen a common situation where attachments are only accepted on certain objects because “the connector was coded that way”.
The Sofia Connector handles attachments on any Salesforce API object that in turn supports them, and this is across traditional lightning UI, Experience sites and Mobile applications.
3. Checkpoints
The ability to save your interview position and return to it is a very common requirement, and the SetCheckpoint and GetCheckpoint operations are there to help us. The devil is in the detail however – since the checkpoint is a Base64 encode d string, where will it be stored? In middleware? In the database? And how will it be managed. The Sofia Connector makes it all seamless with complete support for Checkpoints out of the box.
4. Complex data structures
Dealing with parent – child -grandchild (and beyond) structures in your Connector requires a high degree of reusable code and abstraction. Without it, many custom-built connectors become “single use” and customer’s end up having multiple variations on a codebase to cover various structures, which again means the concept of “build once” is lost forever. And as soon as larger more complex structures come into play, performance issues become very apparent since code that is not optimized can mean long delays as hierarchies are scanned.
Resource Constraints
From a resources standpoint, in your Comparison Matrix you have to consider whether you can afford to have extra feet on the ground to take on new jobs; like the role of an integration server specialist who will map data, create endpoints and handle the specifics of your interviews like attachments and so on.
You will also need to think about how your existing resources might be affected – today with an integration to, for example, Oracle B2C Service, the Oracle Policy Modeler is already familiar with the process of mapping to your application. If that now changes completely – to a loose mapping which is tied together on the Integration Server by a specialist – how are they going to react, and what is the learning curve?
The ability to construct something that is going to be reusable and that can evolve – since the Connector API may provide further functionality in later versions, and authentication might change just to name two examples – is key to this investment and how you sell it internally.
Cost – Upfront and Ongoing
Obviously there is the cost standpoint – each type of approach has different up-front costs and ongoing charges to consider in your Comparison Matrix. Whether you are using existing software or investing in, for example, an integration service, there may be other reasons to work with a particular platform than just immediate up-front cost. If you have already invested in the integration server for other projects, then you can balance the cost against the benefits brought.
So consider all the elements (training, monthly cost, hardware investment as appropriate) when thinking what is right for your scenario.
So with that in mind here is a handy comparison matrix that maybe can help you sketch out a way forward that works for your sccenario.
And since we were discussing these points, here is a video of a good workout for the Connector with some checkpoints, attachments and ExecuteQuery for starters. You can read more about the solution and join the Beta Program by heading to Koltevate and clicking the Join Beta button.
