on 09-12-2020 6:46 AM
Dear Community,
we are looking to build an integration using the OData API, however we noticed that there are duplicated keys in the response the API returns.
More specifically, we are trying to insert job applications. The above mentioned behavior occurs only if the respective job requisition has been assigned more than one screening questions.
Following is a sample request.
{
"resume": {
... an attachment object
},
"jobReqId": 99887766,
"jobApplicationQuestionResponse": [
{
"order": "1",
"answer": "No"
},
{
"order": "2",
"answer": "3-5 years"
}
],
"coverLetter": {
... an attachment object
},
"candidateId": "44444",
"appStatusSetItemId": "1234567",
"appLocale": "en_GB"
}
This is the response we get.
{
"d": {
"__metadata": {
"uri": "<API base URL>/JobApplication(2222L)",
"type": "SFOData.JobApplication"
},
"jobReqId": "99887766",
"candidateId": "44444",
"appStatusSetItemId": "1234567",
"appLocale": "en_GB",
"applicationId": "2222",
"resume": {
... attachment response
},
"jobApplicationQuestionResponse": {
"__metadata": {
"uri": "<API Base URL>/JobApplicationQuestionResponse???",
"type": "SFOData.JobApplicationQuestionResponse"
},
"order": "1",
"answer": "No"
},
"jobApplicationQuestionResponse": {
"__metadata": {
"uri": "<API base URL>/JobApplicationQuestionResponse???",
"type": "SFOData.JobApplicationQuestionResponse"
},
"order": "2",
"answer": "3-5 years"
},
"coverLetter": {
... attachment response
}
}
}
The problem is that the library we are using can't handle duplicated keys (see the properties "jobApplicationQuestionResponse" above) in the response.
Has any of you faced this issue? If so, could you please, describe how this can be solved?
Thank you for your input in advance!
Hi Bence,
It this is really the response from the API:
uri": "<API Base URL>/JobApplicationQuestionResponse???",
I would say this is an issue with the API response the consumer can not fix. The API should not have data like his in the metadata token being returned. It should be a proper URL with the right keys. Might be worth to open a ticket to ask if this will be fixed soon or if this will take a while.
Workarounds for something like this are of cause possible, this would be the order I would try:
Best regards
Gerald
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gerald,
thank you very much for your reply!
(Un)Fortunately, this occurs in a Salesdemo instance. Therefore, we can't submit an incident.
Since this didn't occur in the past, we believe that this is a temporary issue, which will be solved soon.
Thank you for the workarounds, too. We haven't tried to use the UPSERT operation yet. In my opinion, however, the solution would be to solve this issue and not implementing a workaround.
After all, this is a functionality that has been described in the latest version of the documentation as well.
Best regards,
Bence
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
3 | |
3 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.