I can find formats for this using the CLI
aws sns publish --topic-arn arn:aws:sns:us-west-2:111111111111:test
--message "Testing the CLI"
--subject "From the CLI" --message-attributes "{\"somename\":
{\"DataType\":\"String\",\"StringValue\":\"somevalue\"}}"
But what I can't find (or figure out) is how to do this from the Integration Request on an API Gateway.
I believe it needs to be done as Query Parameters of the Integration Request, but the syntax is not the same as adding Message Attributes for SQS. I tested that by using a parameter naming notation along the lines of this example:
MessageBody=This+is+a+test+message
MessageAttribute.1.Name=test_attribute_name_1
MessageAttribute.1.Value.StringValue=test_attribute_value_1
MessageAttribute.1.Value.DataType=String
I also tried:
MessageAttributes '{"store":{"DataType":"String","StringValue":"example_corp"}}'
So far can't get it working, any help is much appreciated.
After thorough research into the AWS docs, I found that there is no accurate documentation of setting up SNS Publish MessageAttributes in an API Gateway Resource Method as URL Query String Parameters.
Based on the partial syntax example they give here: https://docs.aws.amazon.com/sns/latest/api/API_Publish.html, I was then able to throw things at it until something stuck.
This is the proper dot notation syntax and parameters you need to use:
MessageAttributes.entry.1.Name = "Attribute1"
MessageAttributes.entry.1.Value.DataType = 'String'
MessageAttributes.entry.1.Value.StringValue = 'Test'
Where "Name" and "DataType" are required.
Cheers!
Related
I am following the API documents for analyzing text via the API docs here and the examples on github here. When I add the optional parameter to the annotator to get all of the codes like this:
anno_cd = acd.Annotator(
name='concept_detection',
parameters = {'include_optional_fields':'medical_codes'})
I get this:
Error Occurred: Code 400 Message Bad Request CorrelationId
820af2f3-0b25-477a-bde5-20fc57fd4a4d
Does anyone see what I am doing wrong?
It was a problem with the way the parameters were set. You need to build a collection inside a collection. This works:
anno_cd = acd.Annotator(
name='concept_detection',
parameters = {"expanded": ["true"],"include_optional_fields":["medical_codes"]})
So I'm experiencing some issues in Azure Data Factory.
I have a standard pipeline where I'm trying to implement a webhook for later callbacks, but the body for the webhook post does not seem to be behaving.
(In advance: sorry for the image URLs -> I'm not reputable enough to post images)
So here is what I've typed into the "Body" of the Webhook service: https://imagizer.imageshack.com/img922/3765/ApbiRN.jpg
Then I verify that the template looks correct:
https://imagizer.imageshack.com/img924/5448/vN82Vp.jpg
And finally I debug the pipeline only to find this as output from the webhook: https://imagizer.imageshack.com/img923/3697/AEDzOT.jpg
As you can see it's grabbing a {"Key":"Value"} from somewhere.
Now I've saved the pipeline; I've published the pipeline; I've restarted ADF.. Still.
So the first issue is that I'm not able to send the body that I want.
The second issue is that I'd like to parameterize the body (when this is cleared up):
{
"key1":"#{pipeline().parameters.param1}",
"key2":"#{pipeline().parameters.param2}",
"key3":"#{pipeline().parameters.param3}"
}
I've not been able to solve that last one either, so if any kind souls would be so kind.. much obliged!
Edit: In addition I've not been able to spot the "callBackUri" that the documentation promises: https://learn.microsoft.com/en-us/azure/data-factory/control-flow-webhook-activity
Any insights into that issue as well?
I tried many times and finally succeeded.
In your case, you can use the expression as follow:
#json(concat(concat('{"key1":"',pipeline().parameters.param1,'",'),concat('"key2":"',pipeline().parameters.param2,'",'),concat('"key3":"',pipeline().parameters.param3,'"}')))
The result is as follow:
First, we need to concatenate the query string.
Then we need to use #json() to convert the string type to json type.
I am trying to add Lambda#Edge association in cloudfront using cloudformation. As per aws docs they had only two fields like EventType and LambdaFunctionARN . But i want to add IncludeBody in cloudformation so that my Lambda#Edge will read the body of the request . When i try to add IncludeBody in cloudformation it is saying error like invalid property.
"LambdaFunctionAssociations":
[
{
"EventType": "origin-response",
"IncludeBody":"true" -- Invalid property error
"LambdaFunctionARN": "arn:aws:lambda:us-east-1:134952096518:function:LambdaEdge:1"
}
]
So, can't i add this through cloudformation . Or i need to do it manually from console ?
Any help is appreciated
Thanks
According to AWS docs, there is an IncludeBody property for LambdaFunctionAssociations. But they also say that it can only be used for "viewer-request" and "origin-request" EventTypes. It looks like you have an "origin-response" EventType, so IncludeBody shouldn't be applicable here. Yet, in the official CloudFormation reference, there is no mention of IncludeBody. So I can only guess that CloudFormation is missing this feature right now and you may only be able to set IncludeBody via the API.
I'm trying to use a service of DocuSign API in an abap project. I want to send a document to a specific email so it can be signed. But im getting the following error:
"errorCode": "INVALID_REQUEST_PARAMETER",## "message": "The request contained at least one invalid parameter. Query parameter 'from_date' must be set to a valid DateTime, or 'envelope_ids' or 'transaction_ids' must be specified.
I tried the following:
CALL METHOD cl_http_client=>create_by_url
EXPORTING
url = l_url (https://demo.docusign.net/restapi/v2/accounts/XXXXXX')
proxy_host = co_proxy_host
proxy_service = co_proxy_service
IMPORTING
client = lo_http_client
lo_http_client->request->set_method( method = 'POST').
CALL METHOD lo_http_client->request->set_header_field
EXPORTING
name = 'Accept'
value = 'application/json'.
CALL METHOD lo_http_client->request->set_header_field
EXPORTING
name = 'X-DocuSign-Authentication'
value = get_auth_header( ). (json auth header)
CALL METHOD lo_http_client->request->set_cdata
EXPORTING
data = create_body( ).
This is my body:
CONCATENATE
`{`
`"emailSubject": "DocuSign REST API Quickstart Sample",`
`"emailBlurb": "Shows how to create and send an envelope from a document.",`
`"recipients": {`
`"signers": [{`
`"email": "test#email",`
`"name": "test",`
`"recipientId": "1",`
`"routingOrder": "1"`
`}]`
`},`
`"documents": [{`
`"documentId": "1",`
`"name": "test.pdf",`
`"documentBase64":` `"` l_encoded_doc `"`
`}],`
`"status": "sent"`
`}` INTO re_data.
The api request to get the Baseurl is working fine. (I know the error is quite specific what the problem is, but i cant find any sources on the docusign api documentation that one of the mentioned parameters should be added to the request)
Thank you in regards
The error message seems to indicate that you're Posting to an endpoint that requires certain query string parameters -- but you're not specifying them as expected in the query string. I'd suggest you check the DocuSign API documentation for the operation you are using, to determine what query string parameters it requires, and then ensure that you're including those parameters in your request URL.
If you can't figure this out using the documentation, then I'd suggest that you update your post to clarify exactly what URL (endpoint) you are using for the request, including any querystring parameters you're specifying in the URL. You can put fake values for things like Account ID, of course -- we just need to see the endpoint you are calling, and what qs params you're sending.
To create an envelope, use
https://demo.docusign.net/restapi/v2/accounts/XXXXXX/envelopes
instead of
https://demo.docusign.net/restapi/v2/accounts/XXXXXX
Thank you for all the answers, i found the mistake. Creating the request wasn´t the problem. I was using the wrong "sending"-method -_-.
now its working :)
lo_rest_client->post( EXPORTING io_entity = lo_request_entity ).
When I create a resource/method in AWS API Gateway API I can create one of the following methods: DELETE, GET, HEAD, OPTIONS, PATCH or POST.
If I choose GET then API Gateway doesn't pass authentication details; but for POST it does.
For GET should I be adding the cognito credentials to the URL of my GET? or just never use GET and use POST for all authenticated calls?
My set-up in API Gateway/Lambda:
I created a Resource and two methods: GET and POST
Under Authorization Settings I set Authorization to AWS_AIM
For this example there is no Request Model
Under Method Execution I set Integration type to Lambda Function and I check Invoke with caller credentials (I also set Lambda Region and Lambda Function)
I leave Credentials cache unchecked.
For Body Mapping Templates, I set Content-Type to `application/json' and the Mapping Template to
{ "identity" : "$input.params('identity')"}
In my Python Lambda function:
def lambda_handler(event, context):
print context.identity
print context.identity.cognito_identity_id
return True
Running the Python function:
For the GET context.identity is None
For the POST context.identity has a value and context.identity.cognito_identity_id has the correct value.
As mentioned in comments: all HTTP methods support authentication. If the method is configured to require authentication, authentication results should be included in the context for you to access via mapping templates to pass down stream as contextual information.
If this is not working for you, please update your question to reflect:
How your API methods are configured.
What your mapping template is.
What results you see in testing.
UPDATE
The code in your lambda function is checking the context of the Lambda function, not the value from API Gateway. To access the value passed in from API Gateway, you would need to use event.identity not context.identity.
This would only half solve your problem as you are not using the correct value to access the identity in API gateway. That would be $context.identity.cognitoIdentityId (assuming you are using Amazon Cognito auth). Please see the mapping template reference for a full guide of supported variables.
Finally, you may want to consider using the template referenced in this question.