Currently, you need to specify a "hard-coded" AccessKeyId and SecretAccessKey for the SQSReceiver/Sender/Deleter/MessageCounter, or you can set it through a Public/Private Parameter.In the S3Downloader/Uploader/Deleter/ObjectLister, you can omit these values and get them through a file, Java system properties or environment variables. I think it would be nice if this behavior is consistent among these AWS transformers.
Archived
Harmonize access key settings of SQS and S3 transformers
+7This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+7Any news on when the PR is due, @donatsafe?
We are now using IAM Roles on our EC2 instances. This works perfectly with the S3 transformers. Would be nice if the SQS transformers picked up the credentials from the IAM Role as well! Same goes for SQS publications/subscriptions on FME Server, by the way.
Now I am implementing some Boto solution, because we don't want to pass credentials as parameters to a workspace.
Thanks! :)