Context Service for CVP Deregister/Register/Connection

[SEAN NILSEN]

I'm wondering if anyone has been through the Context Service Deregistration process in OAMP for CVP [v11.6(1) for CVP and Ops]?

The reason I ask is that the docs indicate that going through the Deregister button in OAMP should bring up the "Enable Collaboration Cloud Extensions" page.

Instead, the button brings me to a page prompting for "Remove Hybrid Services Cluster" which is clearly not the right page as I don't want to remove the entire config.

Any idea if that is a badly worded page in the WebEx Admin side or if clicking continue there will really remove the Hybrid Services Cluster?

My real issue driving all of this is that my Finesse Context is Operational and working AOK but the CVP Context is in an "impaired" state. The available logs are very insufficient to troubleshoot what the actual underlying issues might be.

The relevant exception using the BuiltIn Customer Lookup element in VXML Server is: "Context service object initialization failed."

Any suggestions on next steps on how to troubleshoot Context Service as it relates to CVP/VXML?

==== Edit 1 ===

As I continue troubleshooting, the system has now reached a state where the VXML Server is throwing:

Caused by: ApiError with errorType: connector.notRegistered errorData: cs_context errorMessage: connector is not registered

But OpsConsole still believes it's registered.

Anyone know if there's a manual way to kick Ops back into an unregistered state and manually clear out the nodes in WebEx Admin?

[SEAN NILSEN]

The answer is - the wording on the WebEx Admin/Deregister page is very misleading.

I'm pretty adventurous so I clicked the "Confirm" button anyway and that reset Ops status and removed only the CVP context.

After re-registering, WebEx Admin shows both Finesse and CVP Context In-Service.

After re-deploying the context config, and rebooting the CVP/VXML server, I am still left with the issue of:

01/03/2019 12:54:35.660, The error was: A built-in element encountered an exception of type com.cisco.thunderhead.errors.ConnectorIsNotRegisteredException. The root cause was: com.cisco.thunderhead.errors.ConnectorIsNotRegisteredException
com.audium.server.AudiumException: A built-in element encountered an exception of type 

<snip>
Caused by: ApiError with errorType: connector.notRegistered errorData: cs_context errorMessage: connector is not registered

Any suggestions?

[SEAN NILSEN]

Currently, I am looking at the c:\Cisco\CVP\conf\vxml.properties file.

Does anyone know if the VXML.ContextService.ConnectionData property should literally equal the value of "Connection Data" from the Context Service Management Page in OAMP?

I'm likely going to try it, just curious if anyone knows already if this is a further hash of that data or ?

[SEAN NILSEN]

It's a hash of the data or some kind; I reverted to the original value that was written by Ops during the registration process.

FYI - it appears that this only happens once, so if you remove the original line and don't have a backup, you'll wind up re-registering again. A save and deploy will NOT republish the Data to the VXML Server.

I stepped back one layer to see what is happening when the VXML Server starts up since the current complaint is about not being connected.

01/03/2019 13:41:32.343, SERVER ERROR: Context service client object creation failed.
ApiError with errorType: invalidInput, errorData: cs_context, errorMessage: missing management cluster ID

There are zero references to this in any of the docs I can find.

I can see some clusterId values in the CCX versions of the "Identify Context Service Status" doc but that is less than helpful.

https://www.cisco.com/c/en/us/support/docs/contact-center/unified-contact-center-express/213809-identify-context-service-status-in-uccx.html

Anyone know where/how this value is supposed to be set?