Google Chat - Update Existing Message using Thread Message via Webhook - google-chat

I am trying to update the existing message in Google Spaces, but it seems my webhook creates a new message every time. Any guidance will be appreciated.
if you look at the webhook i shared it contains a thredkey, i successfully created a message but unable to post Thread message even though using exactly as described by Google but for some reason my Thread webhook is posting a new message and not inside the Thread.
https://chat.googleapis.com/v1/spaces/AAAAxsij123/messages?&threadKey=g3kjfKDp123&key=AIzaSyDdI0hCZtE6vy123-WEfRq3CPzqKqgtHY&token=SE2dKe34qeSC6pvIc8NNCALCiUtdfo3FF5T_fWcFGT8%3D

It seems that you can only use a threadKey that you created with the same webhook, you cannot just grab the key from an existing thread to post in it. This is explained in the documentation here:
Each threadKey is unique to the app that sets it. If two different Chat apps or webhooks set the same threadKey, the messages do not thread. It is not possible to retrieve a threadKey from Chat API. The spaces.messages.thread.name field is the resource name of a thread in Chat API, not the threadKey.
This means that each webhook or Chat app has its own unique way to hash the string you used as threadKey and turn it into a "thread name", but as a result there's no (publicly available) way to do this process in reverse to get the threadKey from the "thread name". If you try to grab the name from an existing thread and add it as a key then it will just hash it again and turn it into a different one.
Essentially this means that, as the documentation explains, you have to create your own thread with an arbitrary string, then save that string to use it in the future. The arbitrary string can be anything so you can use something easy to remember. As shown in the docs:
https://chat.googleapis.com/v1/spaces/SPACE_ID/messages?threadKey=MY_KEY
Then just keep using MY_KEY in future messages and the webhook will post to the same thread. What you cannot do is to grab an existing thread, look for its ID and then try to post to it. The thread has to have been created by the same webhook.

Related

Understanding of OData services

This is a question to improve my understanding about OData and the process of OData services. I'm not sure about the process when an OData request is sent to the server from my Fiori app. The app is added to our Fiori Launchpad. When the user wants to create a new target group in the UI, a create request is sent. What happens then in detail? What I thought so far:
OData service checks the data
If the data is valid, a new entry in the database is created (HTTP POST)
If the data is not valid, the OData service sends an error
I'm not sure about what information is delivered by the OData service and what information is delivered directly from the database? Does the OData service work like a adjustor which transfers the messages sent from the database to the application?
I hope you can understand what I'm trying to figure out. Thank you for your time.
it depends how your backend-methods are implemented. Every Entityset usually has one of these Methods:
Get Entity
Get EntitySet
Create
Update
Delete
There are some more I guess, but these are mostly used by developers. You can redefine every single method and implement your own Business Logic in there.
So, let's assume you want to send data from the Frontend to your service and insert the data into a table inside your database. You have to redefine the create method of your entity and implement own logic. This could contain an insert into a database-table. You have to consider, that your oData Service will throw an Error if the types which are sent from the frontend do not match the Entity-Types (i.e. a String into an edm.Time type).
Here you can find all EDM.Types oData could consume and the correct mapping of the types:
https://help.sap.com/saphelp_gateway20sp12/helpdata/en/76/4a837928fa4751ab6e0a50a2a4a56b/frameset.htm
Hope this helps :)

Contract Tests for APIs which involve session or workflow

Hi I am trying to write Contract Tests for a product purchase workflow. So obviously i cannot call the Checkout API directly without calling Add to Cart API.
But as I have observed the verification hits the paths individually might not be in the same order as listed in the Pact JSON File.
So how should I handle such scnenario which involve session management and workflow(meaning step1 shud be successful only then step2 will be success)
Thanks!
Use provider states to set up the right data in the cart so that when you call checkout, you get the behaviour you want. Here's the documentation from pact.io on provider states.
Each interaction in a pact should be verified in isolation, with no context maintained from the previous interactions. Tests that depend on the outcome of previous tests are brittle and land you back in integration test hell, which is the nasty place you're trying to escape by using pacts.
So how do you test a request that requires data to already exist on the provider? Provider states allow you to set up data on the provider by injecting it straight into the data source before the interaction is run, so that it can make a response that matches what the consumer expects. The name of the provider state is specified in the given clause of an interaction in the consumer, and then used to find the block of code to run in the provider to set up the right data. If you need to stub a downstream system, or return an error response that is difficult to cause in the normal scheme of things (e.g. a 500), this is the place where you can set up stubs.
https://docs.pact.io/documentation/provider_states.html
In your case, this would look like:
Given an item has been added to the cart
upon receiving a request to checkout it will respond with the checkout response....
As an aside, I would also imagine you'd want, given no items have been added to the cart upon receiving a request to checkout it will respond with some other type of response (empty cart? error?)
The provider will need to implement the provider state hook for an item has been added to the cart in the verification code, which will add the item to the cart by inserting it directly into the datasource.

Save query result from GET method for future reference

I want to implement a query on my web page that gets results from another web service and displays them to the user. For this I ofcourse send the request as GET method from the web page. Server side, I process the request, get results from that web service and return them back to user.
However, I also want to save the results for future refernce. Something like history of queries. For this I will store the results in a database.
Now, the question is since I am upating my database everytime a query is made, should I be using POST method on the web page or GET would do? Does HTTP explicitly say anything for this scenario?
HTTP itself doesn't say you have to use POST -- the technology will work just fine if you're sending your data on queryparams.
But current convention says that you should use POST, specifically when using API services under a RESTful model. If you are passing data (even on the query params) that is creating a new record, it should use the POST verb. Updating it should use PUT.
It's going to get down to what your audience expects. If it's just an internal resource, go for it with GET. If you expect to open this up as a public service, use POST.

Accessing workflowArguments in a hosted workflow

We are mixing workflows, a workflow using receive activity's more at the end. But at the start we want to pass in some arguments (not using a receive activity!)
Our workflows are already being created and resumed using a dynamic endpoint with IWorkflowCreation and a class derived from WorkflowHostingEndpoint. In the OnGetCreationContext the creationgContext is filled with WorkflowArguments and the workflow runs. At a later part the receive activity's are creating a bookmark which can be resumed with a message. All seems nice.
But in a xamlx there are no WorkflowArguments, i understand why, except that i want them anyway. I though about an activity in which i can write some code to get the Arguments myself, but i do need some help here.
Or is there another way to pass along the WorkflowArguments into a xamls without using Messaging?
You can't pass arguments into a starting workflow service except through the SOAP message that starts it. But there is nothing preventing you from reading any properties in your workflow service. So it is perfectly fine to do read settings or something similar instead of passing them in at startup.
We have solved this exact situation by creating another WCF service which sits alongside our xamlx service on a slightly different url (e.g. /WorkflowMetadata) and this is where we implement a service method that returns a dictionary of string, type.
In the implementation of this service we simply read the xamlx and determine the arguments.
This is what we use to interrogate a target workflow in an activity designer when creating something like a launch-workflow activity.
Creating an activity will not work as that activity will need an instance in order to run. All you want is some metadata about the xamlx service. And if you are using a WorkflowCreationEndpoint to construct a creation context then you are probably only allowing a dictionary of string, object as the start parameters. Therefore standard metadata will not work. This left us with the only option being to provide another service beside the workflow which serves metadata.
Background here: http://blog.petegoo.com/index.php/2011/09/02/building-an-enterprise-workflow-system-with-wf4/

How do I retrieve version information from a WCF Web Service?

I want to log the assembly version information into a log file each time my WCF web service is called. I know that in an application the My object has an Application object which has the Info structure, that contains the Version string that I can use. How can I get the version information for the WCF service to a log?
You will need to create either a separate service method GetServiceVersionInfo() that you can call when needed, or you could include the service's version info in some headers that travel along with the message.
If you want to add header to each and every message, the best way to go is create an extension called a MessageInspector. This is a small chunk of code that intercepts every message (in your case: every message going out of the server) and adds some header (or manipulates the actual message).
Read up on Message inspectors in this blog post showing how to write a message inspector, or read the MSDN docs on the topic to get started.

Resources