Hi Team,
Regarding Query for conversation details api/v2/analytics/conversations/details/query
Sometimes originatingDirection is null.
In which scenarios it will be null.
Can someone answer my queries
Can you describe how you generated a test call where "originatingDirection" is null? Or can you share the Conversation JSON for that call?
@crespino
Here we don't see originatingDirection property in the schema which is required property.
Normally originatingDirection will be inbound or outbound.
Below is the schema related to conversation happened on 2024-01-12.
Most of the properties are masked with ********** for privacy.
{
"conversationEnd": "2024-01-12T21:42:32.439Z",
"conversationId": "**********",
"conversationStart": "2024-01-12T21:42:15.728Z",
"divisionIds": [
"**********"
],
"participants": [
{
"purpose": "api",
"participantId": "**********",
"participantName": "GS1 Canada",
"sessions": [
{
"deliveryStatus": "DeliverySuccess",
"direction": "outbound",
"mediaType": "email",
"addressFrom": "**********",
"addressOther": "**********",
"addressSelf": "**********",
"addressTo": "**********",
"deliveryStatusChangeDate": "**********",
"peerId": "**********",
"provider": "PureCloud Email",
"remote": "**********",
"sessionId": "**********",
"segments": [
{
"segmentType": "interact",
"conference": false,
"segmentEnd": "2024-01-12T21:42:15.742Z",
"segmentStart": "2024-01-12T21:42:15.742Z",
"subject": "**********"
},
{
"disconnectType": "system",
"segmentType": "transmitting",
"conference": false,
"segmentEnd": "2024-01-12T21:42:32.439Z",
"segmentStart": "2024-01-12T21:42:16.039Z",
"subject": "**********"
}
]
}
]
},
{
"purpose": "external",
"externalContactId": "**********",
"participantId": "**********",
"participantName": "**********",
"sessions": [
{
"direction": "outbound",
"mediaType": "email",
"addressFrom": "**********",
"addressOther": "**********",
"addressSelf": "**********",
"addressTo": "**********",
"peerId": "**********",
"provider": "PureCloud Email",
"sessionId": "**********",
"segments": [
{
"segmentType": "interact",
"conference": false,
"segmentEnd": "2024-01-12T21:42:15.776Z",
"segmentStart": "2024-01-12T21:42:15.776Z",
"subject": "**********"
}
]
}
]
}
]
}
``
My query is in which cases it will be null?The "sessions" array will contain properties specific to the mediaType. Email media types don't likely use "originatingDirection' and instead just use 'direction'. Each media type will use properties that make sense for that media type. For instance emails also contain 'addressFrom' which you phone voice on the session data for a phone call.
1 Like
Could you please let me know the usecase for other media types as well. So that we can make necessary changes in our code.
If you go to the documentation for that API: https://developer.genesys.cloud/devapps/api-explorer#post-api-v2-analytics-conversations-details-query and expand the "API Request" area and then the "200 OK" response we document the properties that should be available to you. Some properties mention what media types they are used by but that's probably not a definitive answer.
I would suggest that you generate test cases for each media type you plan to monitor in both inbound and outbound scenarios and analyze the properties that are returned.
By the way, how did you generate the JSON example you provided? Did you create that Outbound email via the Genesys Cloud API or by some other means? I ask because the particpant.purpose is 'api', so I'm wondering if you generated that test via the Genesys Cloud UI or my making an API call.
I don't know exactly and it is one of our customer data. As we process the past day data daily .our pipelines failed because of data issue described and when analyzed what is the data causing the issue and shared here.
Note: For some customers we will sync every 1hour data and the enddate for interval is current utc time.
But when we pull data with the same interval on next day we didn't experience this issue.
So, are you saying that on the next day originatingOrigin was in that data that time?
Yes , in this case originatingDirection is outbound when reexecuted with same interval on next day
@crespino Hi Jim, they are using the .NET sdk for their queries.
I see in the .NET SDK documentation that for Analytics Conversation we have OriginatingDirection as a parameter, but also the Documentation says its optional, but no further information there
If you use the /api/v2/analytics/conversations/details in API explorer for the same id, OriginatingDirection is present in the response.
@Dileepkaranki, I don't have an answer on why originatingDirection would show up at a later time. It will take some time for me to see if someone can tell me in which case that might happen.
I can tell you that even though an interaction has completed, that doesn't mean that all Genesys services have finished operating on and updating data for that interaction. We have many post call services that can run at various intervals that may update or add properties that are necessary for those services. What you are seeing is likely a case where originatingDirection is add by one of those post-processing services and you are just querying the data too soon for that property to be available.
Regarding the genesys services i know it will run for 24 or 48 hours for correcting the analytics data (/api/v2/analytics) . As you mentioned you will check some other team members. could you let me know once you get response from them.
Hi Team,
Regarding this we opened a case with Genesys #0003467756 and below is the response
- originatingDirection should always be present for conversations, when it is not seen, re querying for those specific conversation Ids that are missing originatingDirection property after a couple of minutes or hours should bring the originatingDirection for that conversation, as our pipeline will have fixed it by then.
- Our Dev team will continue to look into this problem to make sure this property is always present. I think it has been tagged as a bug and will be fixed sometime in the future.
- We'd like to close this case as this fix has not ETA and will likely take a lot of time to be processed. Is that okay? If re processing the query for a conversationId does not bring the originatingDirection you can open a new case and reference this one.
Regarding #3 we are able to retrieve after reprocessing the request.