I have already blogged two different integration pattern between Service Cloud to Eloqua.
This first integration pattern was using Standard Object e.g. Contact object, documented in this blog
The second integration pattern was using Custom Object e.g. Degree Object, documented in this blog.
Now, in this current blog, I am going to cover another integration pattern where bulk data can be imported from Service Cloud to Eloqua using Service Cloud ROQL statement.
In both my previous blogs, data was getting exchanged real time but one transaction at a time, but in this blog data will be transmitted from Service Cloud to Eloqua in bulk for Opportunity Business Object.
This could be one of useful use case wherein you run some marketing campaign recently, which resulted some of the opportunities in Service Cloud and in Marketing cloud you want to reassess campaign performance by looking opportunities data from Service Cloud. Hence, Opportunities data need to be synch with Eloqua in Bulk.
In this use case we will running scheduler integration which will trigger by its own in 10 minute interval and will first get the lists of all new and updated opportunities from Service cloud and then will create the Opportunity Import job in Eloqua and will upload the data to that particular opportunity import job, as result your Opportunities data form Service Cloud to Eloqua will be synched.
Below are the high level steps need to execute to Sync Opportunities in bulk from Service Cloud to Eloqua-
In my previous blog I have focused on how Standard Business Object e.g. Contact can be replicated from Service Cloud to Eloqua.
Now, in this blog focused will be, how Custom Object can be replicated from Service Cloud to Eloqua.
Currently, Service Cloud Adapter only support 3 business object event processing through adapter 1) Contact 2) Incident and 3) Organisation.
If you need to process the event for any other objects, other that what listed above then you need follow the path of Custom Object, Custom Event, associate Custom Event to Custom Object etc.
In this example use-case, I will be creating a Degree Custom object which will hold the value of Contact’s degree information e.g. Degree Name, Degree Status, Email address etc and data will be replicated from Service Cloud to Eloqua whenever that degree object gets created.
Recently, I have been worked for different use-case scenarios between Service Cloud to Eloqua Integration using OIC, hence thought to publish this blog to cover all those scenarios.
This is first in series which will use standard business Contact object data replication, there will be two more blogs, one covering Custom Object replication and another one will be importing data in bulk from Service Cloud to Eloqua.
Before, I start showing the steps how Contact Business Object data can be replicate from Service Cloud to Eloqua. I need to emphasis the important of Service Cloud Adapter and Eloqua Adapter.
Recently I built a Facial Recognition Mobile App using Oracle Visual Builder having set up the Facial recognition APIs using Tensorflow taking some inspiration from FaceNet. As highlighted above the app does the following: record a video of your face and send it to the API that generates various images and classifies them based on the label we provide at runtime. And in turn, invoke another API that is going to train the machine learning model to update the dataset with the new images and label provided. These two APIs will build a facial recognition Database. Once I have this, I can capture the face and compare that with the dataset I have captured earlier in my Facial recognition Database to output if the face exists in our system.
Hashed Timelock Agreements, or Contracts, have emerged as an important concept in the cryptocurrency space in order to perform transactions across ledgers – and I feel could be a valid mechanism to handle the issue of performing verifiable cross-channel transactions in Hyperledger in some use cases. The basic concept of a Hashed Timelock Agreement (HTLA) is that it allows for a conditional transaction (which I have deemed a ‘proposal’) with a cryptographic challenge which ensures it can only be completed by a pre-defined party. This can be chained through multiple intermediaries, which can enable two organisations who do not share a channel to interact, and for transactions to be confirmed across channels.
We know OIC (Oracle Integration Cloud) is capable of file based integration for ERP over API.
And we do know that ODI (Oracle Database Integrator from Data Integration Platform Cloud) is capable of ingesting large file and processing it for ERP through the database layer aka ETL / ELT.
Last week, I had the opportunity to do some work and part of the engagement there was to integrate some data. Easy right? It’s not that hard especially with the technology and standards we have these days. However, what was not apparent upfront until after some digging (ie research), an email and a phone call that there were no APIs to be found. “Ha ha ha … we’ve got you … there is no way you can do it now” So the challenge was accepted and instead of time travelling into the future to find a new way of doing things, I went totally retro. And hence the title “Enter The Robots“. I didn’t go and create new versions of robots or AI. I don’t create a new quantum computing paradigm. What I did do was classically known as screen-scraping. “ick“, I hear from the crowd. “How dare you?“, someone else yells out. But I say this honestly, if there is no other way to integrate and capture data, then I rather do it knowing that it is a last resort.
In this article, I walk through a few of the tips and tricks with what’s currently available to help out in this situation.