I have an application that uses context store to save and retrieve data. My Add and Get tasks work fine, but I cannot get my Update task to work. It always returns this:

{'csStatusOutput':'BAD_REQUEST','csDataOutput':'','csMessageOutput':''}

This input looks like this:

{'csDataInput':'{\'contextId\':\'6512307245\',\'data\':{\'name\':\'Andrew\',\'state\':\'query\'}}','csIdInput':'6512307245'}

For input, I am passing the same data structure I passed when I did the Add. I am also using the same csIdInput as I did with the Add.

This input to the Add looks like this:

{'csDataInput':'{\'contextId\':\'6512307245\',\'data\':{\'name\':\'hi\',\'state\':\'init\'}}'}

Am I doing this correctly? Do I need to do something different for an Update?

Thanks!

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

Perhaps I am missing something, but I still can't get it to work. I only have two values in my CS record -- name and state.

I send this to the Update task:

{'csDataInput':'{\'data\':{\'name\':Andrew\',\'state\':\'query\'}} ','csIdInput':'6512307245'}

And still receive this:

{'csStatusOutput':'BAD_REQUEST','csDataOutput':'','csMessageOutput':''}

I use the same ID (6512307245) as I did in the Add.

Hi Andrew,

When you added the context, did you get a csStatusOutput 'OK' message?
Did you add any additional parameters to the Add Context request e.g. groupId, tenantId or routingId?
Could you please supply the inputs for the Add Context operation.

Also, is it possible that the context's lease had expired before the update request was made?

In order to gather more information about the reason for the BAD_REQUEST response, could you please check the ContextStoreRest log output for the update request? (/var/log/Avaya/services/ContextStoreRest/) and provide the full error message.

Thanks,
Kezzia

There is no ContextStoreRest directory under /var/log/Avaya/services/. There is a CSRest directory, but it's empty.

I am not timing out. I Get the context and immediately attempt to Update it. The Get works fine. The Update fails.

I am attaching two screenshots of the Add. Let me know there is anything wrong with it. I suspect that since I can Get the context, the Add is working as it should.

Hi Andrew,

Which version of Context Store are you using?
If it is 3.4 you should see a 'ContextStoreRest' directory, otherwise it will be 'CSRest'.

If the Add Context/Get Context requests are successful, you should these requests in the ContextStoreRest/CSRest log on one of your Context Store nodes.
Please note that for standalone Context Store deployment, the ED node and the Context Store nodes are separate nodes. Could you please check for this directory again on the CS node?

From the screenshots you shared, it looks as though you are mapping in a value for csIdInput-this is not required.
Please refer to the Appendix of the Context Store Developer Guide as mentioned by Siobhán, in particular subsection 17.8.1.

In order to verify that the 'Add Context' operation was successful, please provide either the ContextStoreRest/CSRest log output and/or a screenshot of the Engagement Designer Admin output of the operation.

To do this please:
1. Navigate to the Engagement Designer ED Admin Page by clicking on the 'Admin Console' button on the top right of the Engagement Designer Design console you are using to create your flow.
2. Click on the 'Instances' tab
3. Click on the Id of the instance created when you added the context (if you're not sure which ID to chose, simply create another context with a different ID and it will be the latest instance. Please note the default Refresh rate is 30 seconds so either wait 30 seconds or change the Refresh rate to 5 seconds in the top left corner).
4. Click on the Context Store task
5. Send a screenshot of the window that opens up.

Regards,
Kezzia

This is a 3.2 Collaboratory. I have no idea where CS is running on these labs.

I removed the csIdInput mapping in the Add. It made no difference.

Here is the input to the Add:

{'csDataInput':'{\'contextId\':\'6512307245\',\'data\':{\'name\':\'Unknown\',\'state\':\'init\'}}'}

Here is the output from the Add:

{'csStatusOutput':'OK','csDataOutput':'','csMessageOutput':''}

Here is the input to the Get:

{'csIdInput':'6512307245'}

Here is the output from the Get:

{'csObjectOutput':{'name':'Unknown','state':'init'},'csStatusOutput':'OK','csDataOutput':'{\'name\':\'Unknown\',\'state\':\'init\'}','csMessageOutput':''}

Here is the input to the Update (which immediately follows the Get):

{'csDataInput':'{\'data\':{\'name\':Andrew\',\'state\':\'query\'}} ','csIdInput':'6512307245'}

Here is the output from the Update:

{'csStatusOutput':'BAD_REQUEST','csDataOutput':'','csMessageOutput':''}

I have attached the CS version info.

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

I am using lab 158. I have the wiki with information, but don't see where it calls out a different server for CS. I have attached an image of what I see when I log into the ED server.

By the way, as an enhancement, you may want to add more information for the the errors by the task. I am all for one-stop-shopping.

I believe I figured out which server it is. Here are all the log entries for today. I hope they tell you something.

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

Can you call me (952-456-3516)? I need to get this working and these back and forth messages are taking too long. Thank you.

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

Milliseconds? Your documentation says seconds:

Context lease time (seconds): The time, in seconds, the information will be stored in the Context Store.

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.