I am getting the below warning message in the automatically generated REST API message flow while creating a REST API (by importing a swagger document) -
"This message flow is automatically generated.
Do not edit this message flow.
If you edit the message flow, your changes will be overwritten without a warning."
The IBM Integration Bus version we are using is V 10.0.0.7
What's the significance of this error? And under what conditions, code (what code) will be overwritten?
You should make the necessary changes using REST API Description. Message flow is generated from this description, so it will be overridden the next time something in REST API Description changes and the message flow is regenerated.
Edit: You can add a subflow to handle errors using error handling in your REST API Description:
Related
There's a lot going on, but I think I've narrowed it down to something simple. I hope someone can provide any kind of guidance as to what in the world I'm doing wrong.
I've got javascript voice (2.0) working with node.js. I can call inbound and outbound, and I can send a call from a studio flow to a javascript client. This all works. The issue is that when a javascript client user presses "reject" (out of the box example code) or the call isn't answered, it's just dropped. It doesn't return to the studio flow, and I suppose it isn't designed to.
To fix this, I am trying to get the call using the example for client.calls(call sid).update, and I can take the call and issue Say commands and play mp3 files as shown in the example. But when I try to return the call to the studio flow using the webhook url (with or without ?FlowEvent=return appended) it fails. I've tried using the twiml: syntax and providing valid twiml, and I've tried using the url: syntax and providing a url that produces valid redirect twiml (using the echo twimlet).
The URL I'm using is https://webhooks.twilio.com/v1/Accounts/{my_account_sid_here}/Flows/{valid_flow_sid_here}?FlowEvent=return (with and without ?FlowEvent=return at the end)
twiml like this;
<Response><Redirect method="POST">https://webhooks.twilio.com/v1/Accounts/{my_account_sid_here}/Flows/{valid_flow_sid_here}?FlowEvent=return</Redirect></Response> (with and without ?FlowEvent=return at the end)
I'm using the Parent Call Sid (the call sid for the stream never does anything so I assume that isn't the one to use) and the call, when updated, results in a voice message that says "We're sorry, an application error has occurred." I don't know if that is coming from studio or the twilio call processor. If I use the example url with the rick roll mp3 it works.
I've checked the debug messages and they seem to indicate that the flow webhook URL is returning a 400 status code. The documentation says to "To retrieve the Studio Webhook URL in your Studio flow, click the red Trigger widget. The URL starting with https://webhooks.twilio.com/v1/... is the Webhook URL for this Flow" and that's where I got the URL which includes the account sid and flow sid, which I've also checked for correctness.
I'm not sure what to try next.
Using SAP Cloud Application Programming Model (CAP), in a Node.js application with Fiori Elements like the bookshop sample,
how can I display a Message Toast
to indicate that an action completed successfully?
Using the request object req passed to the event handler:
req.notify("Your success message goes here!");
See also: https://cap.cloud.sap/docs/node.js/requests#req-msg
Ideally, the message should be translated a.k.a. localized.
See also: https://cap.cloud.sap/docs/node.js/app-services#i18n
The part you are referring to is the backend. I'm not sure if you can trigger Toast Messages from backend. But you need to catch the message and display it at the frontend part of your application by using the MessageToast object.
https://cap.cloud.sap/docs/node.js/requests#req-msg This seems like a suggestion of in which way you "typically" handle the message.
You need to check severity of the message that is returned from the backend (http request) and use MessageToast.show or MessageBox.error or MessageBox.warning etc.
I am having issues running a GET against both the schedules and shifts v1.0 API. The documentation on the MS KB doesn't indicate that this is in preview any more, so I'm unsure what we're doing wrong here. The API is running with an app-only auth token
Postman screenshot
Currently we are doing prelim testing via postman to ensure we can use the API correctly.
The app in question has been given the following permissions:
Schedule.Read.All
Schedule.ReadWrite.All
We can view the teamId information correctly at https://graph.microsoft.com/v1.0/teams/{{TeamId}}, but schedules or schedules/shifts returns the error
Based on a previous answer I saw, I added the MS-APP-ACT-AS header with a UserId to act as, but it returned the same error
Thanks
Try to use this header instead:
MS-APP-ACTS-AS
In your question you wrote:
MS-APP-ACT-AS
(Missing the 'S')
I'm trying to integrate with Priority REST API and using
https://prioritysoftware.github.io/restapi/#Service_Root_URL for this.
But when I'm trying to call some API's (for example https://www.eshbelsaas.com/ui/odata/Priority/tabmob.ini,3/usdemo/ACCOUNTS) I'm getting the error - API cannot be run for this form.
May someone explains to me what does exactly this means? Is there some permission problems?
This message says that the system administrator hasn't exposed this form in Odata.
accoding to https://prioritysoftware.github.io/tryit (which is not working currently), only few forms were enabled: ORDERS, CUSTOMERS and AGENTS
So I have implemented the Asana Webhooks API as described in their documents. I can pass it a project ID and request a new webhook be created. The API successfully sends a authentication request to my application which returns the Security header as described in the Docs. Asana then returns the expected success response, outlining the newly created Webhooks unique ID.
Now if i take this ID and then query the Asana API to show me all configured webhook's on either the parent Workspace or the project resource directly it returns an empty data JSON Object or reports the resource doesn't exist, suggesting the Webhook Ive just created wasn't actually created, despite giving me the expected success response.
Also If I then make a change to a project it doesn't fire the webhook and I don't receive any events on my application.
Strangely everything was working on Friday but today (Monday) I'm experiencing these issues.
Any pointers would be good, Ive been working as the Docs suggest in terms of my request structure and am authenticating using a PAT, Ive even tried a newly created token.
Thanks,
Our webhooks use the handshake mechanism to make sure that it's possible to call you back, but there's always the possibility that subsequent requests can fail. Additionally (although we don't document this very well - there's an opportunity for us) we should immediately try to deliver a (probably) empty event after the handshake (it looks like {"events":[]}. This is kind of like a "second callback" that contains anything that has changed since you created the webhook.
If this fails - or if any subsequent request fails often enough - the webhook will get trashed. "Failure" in this context means returns HTTP response codes other that 200 or 204.
As for why you're having trouble querying the webhook itself, I wasn't able to repro the issue, so we'd have to dive deeper. It should be fine if you:
Specify the workspace
Optionally specify the resource
I tested this out, and it seemed fine. You also might want to directly query the webhook by id with the /webhooks/:id endpoint - note to use the id of the webhook returned by create, and not the id in the resource field.
If you created the webhook (specifically, your PAT or OAuth app was the one making the create request) you should see the information just fine. If you can get the webhook by id, you should see last_failure_at and last_failure_content fields which would tell you why the webhook was unable to make the delivery.
Finally, if you would like to contact us at api-support#asana.com and let them know more details (for instance, the ID of the webhook you're trying to look at) we can look at those fields from our side to see if we can identify what's going on.