We've been doing some testing with the RDC endpoints in Banno and noticed a bizzare issue where, intermittently, a POST request will respond with a 400. Seconds later, submitting the same request will yield a new RDC account as expected. I'm doing my testing in PowerShell, and below are some examples.
New-RDCAccount -userId $userId -accountTypeMarker Checking -name "Text" -accountNumber "XXXXXXXXX"
And the response for this would work, however when I send a request minutes later:
New-RDCAccount -userId $userId -accountTypeMarker Checking -name "Text" -accountNumber "XXXXXXXXX"
#Note that $userId is the same throughout each request
I get this response: The remote server returned an error: (400) Bad Request.
I understand that the error code implies that my body is malformed, but how is it possible that in one request it's acceptable and in the next it's malformed?
Below is the body for each request (with redacted information). The first one is a working example, and the second one is the failed example:
{
"accountNumber": "XXXXXXXX",
"accountTypeMarker": "Checking",
"name": "Text"
}
{
"accountNumber": "XXXXXXXX",
"accountTypeMarker": "Checking",
"name": "Text"
}
Because I feel this issue is a little hard to believe, I've provided screenshots as well with this.
Not working:
Working:
I'm hopeful someone here can help me out here, cause I feel like I'm taking crazy pills looking at this.
Thank you!
Edit:
Here's another example of it working on one instance, and not another with 0 changes to the code (side by side):
Edit of edit:
I can replicate this issue pretty consistently through Banno People AND my own PowerShell script. I feel this is definitely something on the Banno side at this point...
Pictures for Jamies comment:
Working request headers:
Fail request headers (Note that accessing any of the elements yield a null result):
I'm using this endpoint: https://jackhenry.dev/open-api-docs/admin-api/api-reference/v0/rdc/details/#/User%20RDC%20Endpoints/post_a_mobile_api_v0_institutions__institutionId__users__userId__rdcAccounts
Related
I have been reading old blocks from the solana JSON RPC API (using python), but now I am trying to subscribe to the block production on the solana network (to get up live updates).
I tried to pull updates through the RPC API using
{"jsonrpc": "2.0", "id": "1", "method": "blockSubscribe", "params": ["all"]}
This doesn't work, with response: 'code': -32601, 'message': 'Method not found'
Looking at the docs.solana.com info, it states that:
This subscription is unstable and only available if the validator was
started with the --rpc-pubsub-enable-block-subscription flag. The
format of this subscription may change in the future
I assume this means I need to run solana-test-validator --rpc-pubsub-enable-block-subscription, but this just returns:
error: Found argument '--rpc-pubsub-enable-block-subscription' which wasn't expected, or isn't valid in this context
Did you mean --rpc-port?
USAGE:
solana-test-validator --ledger <DIR> --rpc-port <PORT>
I can't seem to find any more information on how to subscribe to blocks using the RPC.
Any ideas or help with what I'm doing wrong?
Thanks in advance
You are correct that the validator has to run --rpc-pubsub-enable-block-subscription. For mainnet-beta usage, it is recommended to either find a private rpc with this enabled or have your own. Please note though, the method is marked currently as unstable.
It looks like rpc-pubsub-enable-block-subscription is not available on the test validator. You can find the full command list here.
This subscription is unstable and only available if the validator was started with the --rpc-pubsub-enable-block-subscription flag. The format of this subscription may change in the future
I'm trying to test the pass_thread_control function on Facebook Messenger, to have my Dialogflow bot direct ongoing conversation to a human operator. So far I'm stuck at even trying to get a "success" code in Graph API Explorer. I have reviewed Facebook's documentation ( https://developers.facebook.com/docs/messenger-platform/reference/handover-protocol/pass-thread-control/ ), carefully looked through different threads here or elsewhere. I have:
Subscribed my Facebook Page to receive messaging_handovers.
Set the Dialogflow chatbot app as the Primary Receiver.
Set the Page Inbox as Secondary Receiver.
...And I keep on getting various errors. For example, I try this request in Graph API explorer:
POST to https://graph.facebook.com/v5.0/me/pass_thread_control
with params:
{
"recipient": {
"id": "myPageID"
},
"target_app_id": "263902037430900"
}
{
"error": {
"message": "Unsupported post request. Object with ID 'me' does not exist, cannot be loaded due to missing permissions, or does not support this operation. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api",
"type": "GraphMethodException",
"code": 100,
"error_subcode": 33,
"fbtrace_id": "AipGijCLKQOwOl6L792ZEgG"
}
}
Maybe the issue is the recipient PSID? This is the only parameter I have no idea where to get. What is the page scoped app-id? How do I get it?
Or maybe I missed some permissions...?
Any help getting me unstuck much appreciated...
Okay, I actually managed to figure it out.
First and foremost - I discovered the Page I was trying to pass the thread control to wasn't linked to my Facebook Business account and the chatbot app was. I added the page in Facebook Business Manager so that it's linked to the same business account as the chatbot app. NOTE: I am not sure that this is a prereq for everyone, so take caution. It might not be required in all scenarios.
To retrieve the Page PSID, which can then be used in the 'recipient' param of the POST request to pass_thread_control, Sent a GET request using Graph API Explorer as shown here: https://developers.facebook.com/docs/facebook-login/connecting-accounts#examples
Even though the example request does not contain the appsecret_proof param, I used it and haven't tested the request without it. A very simple way of generating appsecret_proof using PHP is shown here: https://developers.facebook.com/docs/graph-api/securing-requests#generate-proof
Then when providing the PSID obtained using method shown in point 2., I got "success:true" while testing the pass_thread_control, which did pass the thread control to Secondary Receiver = Page Inbox. Yaaay! 😊
All of the above is described also in this thread, which helped me figure it out, so credit to Sunil: Is Facebook Messenger PSID PageScope constant for User
We've got reports that sometimes actionable messages are not displayed correctly by some clients. It doesn't matter if they message is displayed on Outlook OWA or Outlook Desktop app.
I asked one of the clients to install Actionable Message debugger app and check the diagnostics section and others. Here are some details I've managed to read off from it:
No card is attached to this message.
Actionable messages processing has not been performed on this message. Actionable messages are only enabled for Office 365.
Adaptive card payload found but could not be parsed. Please validate the payload.
And diagnostics section:
"CardEnabledForMessage": false,
"ClientName": "OutlookWebApp",
"ClientVersion": "16.2528.7.2602797",
"InternetMessageId": "<ID>",
"Error": "EntityDocument does not exist.",
-
"AdaptiveCardPayload": {
"found": true,
"type": "AdaptiveCard"
},
-
"MessageCardPayload": {
"found": false,
"type": null
},
-
"AuthHeader": {
"results": "<address>; dkim=none (message not signed) header.d=none;<address>; dmarc=none action=none header.from=<address>;",
"authAs": "Internal"
}
Up until recently, I wasn't able to reproduce the issue on my end. During some tests, I've sent myself a test message and it has not been parsed correctly.
When I sent another test message afterwards, it was working perfectly fine.
Of course after comparison of both messages' sources yielded that both sources were identical. Headers were a little different but mostly in time and what appears to be the server. Diagnostics and error sections from debugger are almost identical.
The method we use is SMTP (there were some issues with EWS) and we're thinking of switching back if that causes the issue.
Is there something that can be done in regards to this issue? It's probably worth noting that the payload we send is quite 'heavy' (as in, we had to limit ourselves with the amount of data we send because we were hitting something what looked like size limit)
Changing the script slightly makes the messages render for some users. Others had to wait some time (possibly for some OWA update?) for them to work.
So in the end nothing has been changed and it started working after some time.
I started using API.AI and Dialogflow in its first versions for some small time projects.
Recently I wanted to try and dive into the new V2 of Dialogflow and see how I can continue to build nice Google Assistant apps with that.
When trying to formulate a response (based on the documentation here https://dialogflow.com/docs/reference/api-v2/rest/v2beta1/WebhookResponse) I am unable to actually render responses of any kind. Everytime I do it just gives me a webhook error back.
The intent That I'm using in my demo project is (still fairly simple as I'm just trying to get a response back):
My Webhook (Elixir based) returns the following response (actual production response):
When inspecting the "Show JSON" After doing the test on the right-hand side of the Dialogflow screen I receive:
I must be doing something wrong, should the whole response that I send now be wrapped in something?
Update:
When removing "fullfillmentText" and just keeping "fullfillmentMessages" I seem to get the same error, but then for fullfillmentMessages. It looks like DialogFlow doesn't understand the JSON parameters I'm sending to it. example:
Man, what a typo here... Managed to fix it in the end by writing "fulfillmentMessage".
Protip for everyone starting with this and wanting to know the structure of data:
Make a simple intention, just as a test
Add some google or other responses trough the GUI
Save the intention
Trigger the intention from the "tryout now" function on the right-hand side.
Click SHOW JSON to inspect how a response would need to look.
Final result Code sample:
{
"fulfillmentMessages": [
{
"platform": "ACTIONS_ON_GOOGLE",
"simpleResponses": {
"simpleResponses": [
{
"displayText": "Sorry, something went wrong",
"ssml": "<speak>Sorry, Something went wrong <break time=\"200ms\"/> Please try again later</speak>"
}
]
}
}
]
}
What I'm trying to do is to get JSON data (whatever it is just make sure I can get anything is ok) from Rallydev without login to make sure that Rallydev is on. I tried several ways, but each way requires a username and password. Would anyone provide a URI for this? Thank you, Guys. Anything you give would be appreciated.
String url = "link";
Client client = Client.create();
WebResource webResource = client.resource(url);
String s = webResource.get(String.class);
try {
// check if RallyDev service is up
if (s.contains("Hello it is now "))
_log.information("RallyDev is working... at " + new Date());
} catch (Exception e) {
_log.error(ErrorCodeEnum.INTERNAL_ERROR, "RallyDev service might be down!!! in " + new Date(), e);
}
Ok, so whether it's Jersey client or plain old HTTP GET against Rally, I'm coming back to my original comment that developing a Java app to do this is a bit overkill. You could accomplish the same thing with a one-line curl command in Linux:
curl -u 'rallyuser#company.com:rallypassword' https://rally1.rallydev.com/slm/webservice/1.33/hierarchicalrequirement.js?pagesize=1
A valid (Rally is up and responding) response to this might look like:
{"QueryResult": {"_rallyAPIMajor": "1", "_rallyAPIMinor": "33", "Errors": [], "Warnings": [], "TotalResultCount": 84, "StartIndex": 1, "PageSize": 1, "Results": [{"_rallyAPIMajor": "1", "_rallyAPIMinor": "33", "_ref": "https://rally1.rallydev.com/slm/webservice/1.33/hierarchicalrequirement/12345678910.js", "_refObjectName": "My Story Name", "_type": "HierarchicalRequirement"}]}}
Looks like you're using Jersey Client to setup a REST connection in Java. Are you really needing to do this without providing credentials? You'll need to pass credentials of some sort as any query-able endpoint in Rally is going to require HTTP Basic Authentication.
If you are looking for the appropriate REST syntax and endpoints to formulate a valid query, you may wish to look at our Webservices API documentation on REST queries:
https://rally1.rallydev.com/slm/doc/webservice/rest.jsp
As an example, a valid REST URL to do a query and get back JSON-formatted results is as follows. A GET against the following sample URL queries user stories owned by user: user#company.com:
https://rally1.rallydev.com/slm/webservice/1.33/hierarchicalrequirement.js?query=(Owner = "user#company.com")&pagesize=1
This would return the first matching User Story.
A simple example of accessing Rally REST services in Java is here:
http://www.rallydev.com/help/basic-rest-client-operations-java
And a full (alpha-release) Java REST API toolkit for Rally is here:
http://www.rallydev.com/developer/java-toolkit-rally-rest-api
All of the above seems like a bit overkill for just finding out if the Rally service is up. You can subscribe to Rally's status updates via RSS at http://status.rallydev.com as a good way to stay apprised of system status information.
I hope this helps - if the answer is off-target, please provide some further clarifying comments and we'll do our best to answer.