Hi Chris Kim,

That sounds like a documentation error.
There were changes made to the Datastore package during the 3.6 program, so the the latest version should be used to be compatible with the CustomerManagement API of Oceana

Regards,
Siobhán

Hi Koen,

It's the name of the service that your using and you've referenced in this question - Streams.

Streams-<release-version-number-you're-using> is the parameter you must use.

If you're using 3.5.0.0, then the GA version number is 3.5.0.0.901401 therefore the parameter you use would be Streams-3.5.0.0.901401
You can confirm what service version you have installed from Element Manager as I mentioned in previous response

Regards,
Siobhán

Hi Koen,

You must use the version that is currently installed on the cluster.

Regards,
Siobhán

Have you enabled CORS on the cluster? (section 12.2.1 step 3)

Are you using the URL above in the JavaScript Test Client (section 12.3.1) or trying to access it directly in browser?

Looks like your attempting to use an unsecured connection, so steps in section 12.2.2 should not be necessary

Hi Koen,

The version required is the version of the Streams snapin service installed on your cluster.

For 3.5.0.1 release, that's Streams-3.5.0.1.52100601 (you can confirm the version by checking Breeze Element Manager "Cluster Administration" or "Service Management" pages)

Regards,
Siobhán

Are you using a multi-node CS cluster? If so you must check the log on each node as requests are round robin - you've only attached one log file


FYI @Anurag, Wilder's environment is running version 3.4.0.0

To determine if the request is reaching Context Store, but failing (e.g. invalid input, problem with CS service), you need to consult the appropriate service log. Details about accessing logs are given in the document referenced in my previous post.

If you're using ContextStoreTasks - the applicable service is ContextStoreRest service

Hi Wilder,

The issue with that reference post was ultimately with setup/configuration.

An error shown in the EDlog is an indication of general problem, but that problem could be anything from your configuration, product issue, incorrect usage etc.

The Context Store Reference Guide contains a troubleshooting chapter (with FAQ) which will help you verify that your Context Store deployment is in working order. http://support.avaya.com/css/P8/documents/101051175

If the CS deployment is healthy but your workflows are not functioning correctly, the problem is with either your ED cluster (in which case request is not reaching CS - you can verify this in ContextStoreRest service log) or the usage of CS API. If your request is reaching the CS cluster but failing, the specific reason for request failure will be logged in the ContextStoreRest service log)

Regards,
Siobhán

P.S. Context Store standalone product should be deployed using the "Context Store" cluster profile as described in deployment documentation; this profile is explicitly tuned for this product. In Oceana solution, it's deployed on "Customer Engagement" profile, which is tuned for that solution

Apologies for misinformation. Yes the parameter is in seconds but 60 seconds is too short for your purpose as I can see from the activity in your log file. 50% of your READ requests to Context Store are failing.

Hi Andrew,

A phone call is not sufficient, we need to see what you're doing in ED to figure out the problem with the data your submitting. This is why we've requested screenshots and logs.

Set up a Scopia call for tomorrow with Kezzia and myself. You will need to share your screen so we can observe how you're using the CS Tasks update operation

Regards,
Siobhán

The attached log file has indeed highlighted two usage problems

(1) You're explicitly setting very short lease times on Context objects ("Lease[60]"). This explains why there are many "Failed to get Context" errors in the log excerpt you send. The lease time input is in milliseconds, so please update your workflow to more workable life-span for context objects

(2) The validation failure reports that the data received for update is empty (though it appears you're submitting input in that field, incorrectly formatted input means it cannot be interpreted). Please send a screenshot of the exact input you're submitting in that update task. As I mentioned yesterday, the strings that you're pasting into this forum are not what's passed to Context Store from your ED workflow.

Regards,
Siobhán

Hi Andrew,

"BAD_REQUEST" means you input failed validation, the specific reason for validation failure is always given in the CSRest service log file.
It is necessary to check the CSRest log file for failure reason. Without this insight as to what problem is, it's very difficult to assist you.

The strings that you're pasting into this forum are not what's passed to Context Store from your ED workflow. These contain escape characters and using inverted commas instead of quotation marks - therefore are not valid JSON data. Need to know what's actually being passed in order to identify the problem with it; the CSRest log file gives exactly that information.

If you are unsure how access log files, this should be covered in the Collaboratory documentation and/or access information. Oralternatively send on the given details of the Collaboratory you're using, and we can reach out to the Breeze team to request the necessary access information on your behalf.

Regards,
Siobhán

Hi Andrew,

The data structure is different for 'update' operation than it is for a 'create'.

There are examples of all operations (on all CS APIs including CS Tasks) in the Appendix of the Context Store Developer Guide. See 17.8 "ContextStoreTasks Type (ED) operations" > sub-section 17.8.8 "Update Context"

csDataInput {"data":{"key1Name":"value1Updated","key3Name":"value3"}}

Regards,
Siobhán

First confirm that the Context Store cluster is functioning correctly. Use the CSRest interface or live test API.

Check if the CSRest log indicates when a request to create 'csPdcTestContext' was received. If not, your OD environment is not targeting your Context Store cluster correctly. Does the log file notes anything about the attempt? text below is the explicit output written by the sample application only.

Note, 302 is not a status code generated by the Context Store itself. This is a common status code that implies the URL you're attempting to access is no longer at the same location.

Hi Kamal,

The version depends on which version of Context Store you're working with.

For example, when you download the CS 3.2.1.0 SDK from DevConnect, you can see that the jar version it contains is cs-sdk-api-3.9.2.jar therefore 3.9.2 is the version you use in your dependency.

The version does not need to be specified in the artifactId explicitly, just "cs-sdk-api".

See also forum post http://www.devconnectprogram.com/forums/posts/list/20502.page#p146964 which is related to use of the Context Store SDK.

Regards,
Siobhán