Develop an Oracle Eloqua app firehose service
Eloqua's firehose service type enables third-parties to build a service that receives a notification when a marketer performs an action in Eloqua. When a marketer creates a campaign or edits an email, for example, Eloqua can call out to the third-party with the update.
Firehose supports subscriptions to a wide variety of events for the different asset types:
- Email: Created, Updated, Deleted
- LandingPage: Created, Updated, Deleted
- ContactSegment: Created, Updated, Deleted
- Form: Created, Updated, Deleted
- Campaign: Created, Updated, Deleted, Draft, DraftApproved, DraftWaitingApproval, ActivatedBySchedule, CampaignLandingPageAdded, CampaignEmailAdded, CampaignFormAdded, CampaignLandingPageRemoved, CampaignEmailRemoved
- Program: Created, Updated, Deleted, Draft, Activated, Paused
When you configure your app, you specify which events to subscribe to in the pattern. Then, when a marketer triggers one of those events, Eloqua calls out to the configured notification URL with the data specified in the firehose pattern.
For example, AwesomeApp has a firehose service and is configured to request all campaign-related events. The call to its notification URL would then resemble:
POST https://example.com/firehose
{
"siteId": "123",
"assetId": "9999",
"assetType": "Campaign",
"eventDate": "12/12/2014 12:00:01 AM",
"eventType": "Updated",
"userId": "1234",
"userName": "Docs.Example",
"msgAttributes": {
"name": "name_of_updated_asset",
"statuschangedby": "1234",
"statuschangedat": "12/12/2014 12:00:00 AM"
},
"oath_consumerkey": "stuff"
}
Eloqua signs all outgoing calls with OAuth 1.0a so the receiving system can validate that the call was sent by Eloqua. Refer to the OAuth 1.0a spec or OAuth 1.0 RFC for more information.
Note: If a firehose service is configured to receive form-related or segment-related events, app providers should expect to see two events whenever a form or segment is created or saved. When a form is created, Eloqua sends a POST request (for the creation) and a PATCH request (for the update). App providers should expect to see two events in these scenarios.