Discussions
Product Notice: Support for Native Salesforce Integration Ending Feb 1, 2021
Comments
-
@greg.staunton nobody will slam you for a sales pitch, however please stick to the facts. As communicated earlier, the native integration will continue to work after Feb 01, 2021, however related support inquiries will not be processed. In addition, I'm not aware of any recent or non-recent SFDC or OSC Apps outages that lasted three weeks. If you have other information, please share it here or contact me directly.
Thank you,
Nathan
Hi Nathan and everyone - I should have perhaps given more detail to the problems I suffered on the Eloqua OSC integration app. It was very new, this was at the start of 2018. We had used the app to build the integration and we were going through our own tests, the analyst assigned to me and the person from the client organization that was going to be the Eloqua admin.
I told them that these had to be end to end tests and under no circumstances should they try to force anything. They decided that meant they should force the hell out of everything, fix defects there and then and then when some contacts got stuck decided to keep reinstalling the app on top of itself. The end result was really weird and the Oracle support team, bless them had never seen this problem that htey had created. Essentially they had reinstalled the app several times on top of its self and the whole thing was totally broken.
This wasnt an outage - so apologies if it came off that way.
The point I was trying to make was that I would still keep the native integration as a back up for disaster recovery.
I am a big time team Eloqua man and I don't slate support or the platform! Because it and they are the best in the world!
-
Hi Oracle,
I'm hearing indications that there have again been app cloud issues with records stuck. I took a a look at my programs again yesterday, and see records stuck in apps from 4 days ago, 6 days ago, yesterday, etc. Can you please update everyone on the progress for this? There have been releases that have targeted this, but it still seems to be an issue.
Previous comments I've made have apologized and mentioned that's not the intention to manually move. But it's still happening. Can you please reconsider your february date for end of support for the integration that does not have these issues? We can't afford to move to an integration for our lead flow that requires us to check our programs manually every day.
-
Hi Oracle,
I'm hearing indications that there have again been app cloud issues with records stuck. I took a a look at my programs again yesterday, and see records stuck in apps from 4 days ago, 6 days ago, yesterday, etc. Can you please update everyone on the progress for this? There have been releases that have targeted this, but it still seems to be an issue.
Previous comments I've made have apologized and mentioned that's not the intention to manually move. But it's still happening. Can you please reconsider your february date for end of support for the integration that does not have these issues? We can't afford to move to an integration for our lead flow that requires us to check our programs manually every day.
Hey Kevin,
So we used to use Oracle integration cloud for our integration into ADW.
We used to used to get this issue and I know your pain, it used to p*** me off too.
At the end of the day we have to improvise adapt and overcome. Not cry into our pints at the end of the day about problems.
We used to use to a cheap and nasty trick that works using the route contacts that get stuck to a wait step. The wait step was a wait 0.01 hours and it worked. When the API started being naughty this was a way that hammered it to work.
I have an article which is referencing the form submit app but it's the same thing. The form submit app would stop working for no reason as well. But this makes you boss, not the connector
https://greg-staunton.com/eloqua-form-submit-app
Please let me.know how you get on. If you have any problems (I dont think you will) hit me up on my context form and I will happily go through it for half an hour with you. I'm unemployed now anyway soni have nothing else constructive to do lol and it will be my pleasure.
-
Hey Kevin,
So we used to use Oracle integration cloud for our integration into ADW.
We used to used to get this issue and I know your pain, it used to p*** me off too.
At the end of the day we have to improvise adapt and overcome. Not cry into our pints at the end of the day about problems.
We used to use to a cheap and nasty trick that works using the route contacts that get stuck to a wait step. The wait step was a wait 0.01 hours and it worked. When the API started being naughty this was a way that hammered it to work.
I have an article which is referencing the form submit app but it's the same thing. The form submit app would stop working for no reason as well. But this makes you boss, not the connector
https://greg-staunton.com/eloqua-form-submit-app
Please let me.know how you get on. If you have any problems (I dont think you will) hit me up on my context form and I will happily go through it for half an hour with you. I'm unemployed now anyway soni have nothing else constructive to do lol and it will be my pleasure.
thanks Greg. unfortunately this only works if eloqua reports an error and does the error routing. The issue we've reported for years and that is still happening is the contact just getting stuck in there. the error routing is set up, but the app doesn't report an error so it doesn't get routed. Just stuck in the step. There is no workaround for this other than to check these "automated" programs manually daily...and that just doesn't suffice for a leads program
-
thanks Greg. unfortunately this only works if eloqua reports an error and does the error routing. The issue we've reported for years and that is still happening is the contact just getting stuck in there. the error routing is set up, but the app doesn't report an error so it doesn't get routed. Just stuck in the step. There is no workaround for this other than to check these "automated" programs manually daily...and that just doesn't suffice for a leads program
Kevin, like I said I have literally nothing going for me workwise and this sounds like a challenge. I know we would need to do NDAs and things like that but I would love to try and get to the bottom of this with you if you will let me, obliviously it would be pro bono. As long as you are happy to let me write up the solution on my blog - I am happy to leave out names, in fact anything you want as long as you will sign off on for me to publish the article I am all yours. email me, [email protected] if you are interested. If not I will take no offence but I am sure that together and even collectively as Eloqua users we will find a solution to stuck contacts. When I go into work and I get a challenge like this I love it. For me it's like a game with a set of rules and I have to use those rules, bend them because I can't change them, play them off on each other and at the end come up with a solution no matter how strange it is. It's a bit like the days I was in the army and in a very, very cold place. If it looks stupid but keeps you warm, it isn't!
-
Hi Oracle,
I'm hearing indications that there have again been app cloud issues with records stuck. I took a a look at my programs again yesterday, and see records stuck in apps from 4 days ago, 6 days ago, yesterday, etc. Can you please update everyone on the progress for this? There have been releases that have targeted this, but it still seems to be an issue.
Previous comments I've made have apologized and mentioned that's not the intention to manually move. But it's still happening. Can you please reconsider your february date for end of support for the integration that does not have these issues? We can't afford to move to an integration for our lead flow that requires us to check our programs manually every day.
Regarding the currently stuck records, please add the details to an SR and or send them directly to me at [email protected]. We want to fully investigate any instances of stuck records when possible. Note, the records need to be left in the step in order to investigate.
Stuck records in apps is an issue we've been tracking closely for over a year. As the issue is rooted in several sources, we continue to perform detailed analysis on ways to address this as best possible. Ultimately, we are making improvements in three main areas:
- More visibility and control for the app user
- More features for the app developer
- Infrastructure improvements
Completed and currently planned work includes:
- 20A (released mid February 2020) - introduced the ability to set records as errored in bulk, helping developers of apps set records to error status to allow them to continue to flow through a canvas when currently unrecoverable errors happen. Partner apps may need to be updated to support this, Oracle authored apps will supported this new capability immediately.
- 20B (released mid May 2020):
- Improved retry strategy for exports for apps. This is expected to address many instances of stuck records where issues with exporting data occur. This will be an update to Eloqua's Bulk API, no apps will need to be updated to absorb this change.
- Token refresh improvement. If the current access token has not been used, submitting a request to authenticate with the previous refresh token will now return the existing new access token and refresh token. This update alleviates the need to have to reinstall an app if there is a server error during token refresh.
- Error Visibility Improvements for app developers:
- We've added a new, more detailed error message for 500 error responses to Bulk API requests. The new error response indicates the type of error, error severity, and when users should retry the request. This new error message provides Bulk API users with more information regarding failed requests, and guidance on when to retry requests.
- New Bulk API sync log message. In certain cases where an export sync attempt fails but Eloqua will retry, Eloqua will now return a message indicating Eloqua will retry the sync. The new status code ELQ-00145 indicates your sync will be retried, and the message indicates when Eloqua will retry the sync.
- Execution Id added to app step member export, to provide app user and developer more visibility.
- Retention implemented for deleted Bulk API definitions. This will help with performance and stability, and will be transparent to app developers.
- 20C (mid August release):
- More granular, informative, and visible messaging within Eloqua to help bring awareness and insight to what state records in app steps are currently in. This will help users become aware of what actions Eloqua, and the app, are currently performing.
- New retry strategy for Notification URL calls to apps. Eloqua will being retrying the Notification URL call over approximately an eight-hour period of time with a backoff strategy.
- Validation improvement for app developers. The app developer will now receive validation error on definition (export, import, and sync action) creation or update to confirm the app service instance (in sync action or filter) exists.
- 20D (mid November release):
- Continuing to add more granular, informative, and visible messaging within Eloqua to help bring awareness and insight to what state records in app steps are currently in. This will help users become aware of what actions Eloqua, and the app, are currently performing.
- Data retention will be applied on Bulk API syncs. This will help with performance and stability, and will be transparent to app developers.
- App member status update optimization. This optimization will help reduce errors when app developers are updating the app member status using the Bulk API.
- Longer term (release yet to be determined)
- Enable App Developer to retrieve unprocessed executions.
- Surface major app failures in the Canvas and via a dashboard in the Marketing Operations Center.
- Provide notifications for major app failures and or stuck records.
There may be additional items or changes to this list as we make progress. -
Regarding the currently stuck records, please add the details to an SR and or send them directly to me at [email protected]. We want to fully investigate any instances of stuck records when possible. Note, the records need to be left in the step in order to investigate.
Stuck records in apps is an issue we've been tracking closely for over a year. As the issue is rooted in several sources, we continue to perform detailed analysis on ways to address this as best possible. Ultimately, we are making improvements in three main areas:
- More visibility and control for the app user
- More features for the app developer
- Infrastructure improvements
Completed and currently planned work includes:
- 20A (released mid February 2020) - introduced the ability to set records as errored in bulk, helping developers of apps set records to error status to allow them to continue to flow through a canvas when currently unrecoverable errors happen. Partner apps may need to be updated to support this, Oracle authored apps will supported this new capability immediately.
- 20B (released mid May 2020):
- Improved retry strategy for exports for apps. This is expected to address many instances of stuck records where issues with exporting data occur. This will be an update to Eloqua's Bulk API, no apps will need to be updated to absorb this change.
- Token refresh improvement. If the current access token has not been used, submitting a request to authenticate with the previous refresh token will now return the existing new access token and refresh token. This update alleviates the need to have to reinstall an app if there is a server error during token refresh.
- Error Visibility Improvements for app developers:
- We've added a new, more detailed error message for 500 error responses to Bulk API requests. The new error response indicates the type of error, error severity, and when users should retry the request. This new error message provides Bulk API users with more information regarding failed requests, and guidance on when to retry requests.
- New Bulk API sync log message. In certain cases where an export sync attempt fails but Eloqua will retry, Eloqua will now return a message indicating Eloqua will retry the sync. The new status code ELQ-00145 indicates your sync will be retried, and the message indicates when Eloqua will retry the sync.
- Execution Id added to app step member export, to provide app user and developer more visibility.
- Retention implemented for deleted Bulk API definitions. This will help with performance and stability, and will be transparent to app developers.
- 20C (mid August release):
- More granular, informative, and visible messaging within Eloqua to help bring awareness and insight to what state records in app steps are currently in. This will help users become aware of what actions Eloqua, and the app, are currently performing.
- New retry strategy for Notification URL calls to apps. Eloqua will being retrying the Notification URL call over approximately an eight-hour period of time with a backoff strategy.
- Validation improvement for app developers. The app developer will now receive validation error on definition (export, import, and sync action) creation or update to confirm the app service instance (in sync action or filter) exists.
- 20D (mid November release):
- Continuing to add more granular, informative, and visible messaging within Eloqua to help bring awareness and insight to what state records in app steps are currently in. This will help users become aware of what actions Eloqua, and the app, are currently performing.
- Data retention will be applied on Bulk API syncs. This will help with performance and stability, and will be transparent to app developers.
- App member status update optimization. This optimization will help reduce errors when app developers are updating the app member status using the Bulk API.
- Longer term (release yet to be determined)
- Enable App Developer to retrieve unprocessed executions.
- Surface major app failures in the Canvas and via a dashboard in the Marketing Operations Center.
- Provide notifications for major app failures and or stuck records.
There may be additional items or changes to this list as we make progress.Thanks for the update on this longstanding issue, @Lou Patrick.
Are you able to provide further details as to whether and how the changes of 20C and 20D will be adopted by Oracle's own Apps (SFDC integration, Form Submit, etc.)?
Post edited by Unknown User on -
Thanks for the update on this longstanding issue, @Lou Patrick.
Are you able to provide further details as to whether and how the changes of 20C and 20D will be adopted by Oracle's own Apps (SFDC integration, Form Submit, etc.)?
All the 20C and 20D updates benefit all apps without any action required from the app developer:
- Infrastructure Improvements (Error reduction / Error Handling)
- New retry strategy for Notification URL calls to apps. Eloqua will being retrying the Notification URL call over approximately an eight-hour period of time with a backoff strategy.
Data retention will be applied on Bulk API syncs. This will help with performance and stability, and will be transparent to app developers.
App member status update optimization. This optimization will help reduce errors when app developers are updating the app member status using the Bulk API.
- Validation improvement for app developers. The app developer will now receive validation error on definition (export, import, and sync action) creation or update to confirm the app service instance (in sync action or filter) exists. (The validation update enables a better experience for the app developer, and is an app flow error handling improvement for the developer.)
- More visibility and control for the app user
- More granular, informative, and visible messaging within Eloqua to help bring awareness and insight to what state records in app steps are currently in. This will help users become aware of what actions Eloqua, and the app, are currently performing.
- There is one new status the app can set ("invalid"), which Oracle's apps are planning to start using when appropriate in future releases.
- More granular, informative, and visible messaging within Eloqua to help bring awareness and insight to what state records in app steps are currently in. This will help users become aware of what actions Eloqua, and the app, are currently performing.
- Infrastructure Improvements (Error reduction / Error Handling)
-
Hi Oracle team,
Native integration supports both Create/Update actions under same external call for campaign association. But it is not possible in the Salesforce.com app to have both create/update in same actions and we will not be able to manage multiple campaigns at the same time for the same contact, otherwise we would have the risk to have few failures (wrong combination of campaign and member id. This is due to the campaign member ID that can be stored only once at contact level).
-
Is there already a date (estimation) known when this will be sunset?
-
Hi Insiders Team!
We have installed SalesForce Integration App and successfully sync data.
In the beginning it was taking only seconds to complete an action.
For the last 10 days it has taken minutes, hours to complete action.
I've put in SR 3-25680412131 - to which I received this response. Could you check more than one action and advise please?
Support ticket Notes (30 mins ago)
Hi Brinette,
Thank you for your patience here.
Our team have looked into the 1 hour processing time for April 15th, 2021, 5:44:48 am
Here are the Kibana details:
logstash_timestamp
April 15th 2021, 05:44:52.854
'state':'CRM_WRITE_RECORDS_TO_DATABASE_STATE'
logstash_timestamp
April 15th 2021, 06:04:10.688
'state':'_SFDC_Microservice_Process_Started'
logstash_timestamp
April 15th 2021, 06:23:58.154
'eventstate':'PROCESSING_RECORD'
logstash_timestamp
April 15th 2021, 06:24:05.445
'eventstate':'COMPLETE'
This means that the action started at 5:44 am, and sent it to SFDC at 5:44 and then SFDC took almost 40 minutes to process the records. In this case, the dlay was not due to Eloqua.
Please let us know if you have further questions.
Thank you!
Regards,
Jaipaul
