kzhou
Former Employee
Joined 9 years ago
User Profile
User Widgets
Contributions
Re: How to do a handshake with SNS Subsbription?
Hi @deepak.shaw , I tried the same last week as well, and unfortunately didn’t make it work. The ultra tasks require either a Bearer token, or a basic auth if the bearer token is not set. I failed to make subscriptions using either of the authentication. I wasn’t able to find a way setting bearer token in the SNS subscription (maybe it would be a question or feature request for AWS SNS team). They do provide a way to include basic auth credentials inside the ‘endpoint’ request parameter. But as I have tested, if the username is an email address, it won’t work since it will break the url format. For now, I would suggest to subscribe the SQS queue to the SNS topic, and use a SQS Consumer Snap to consume the message and trigger a downstream pipeline. Also, if you find any other solutions, please let me know.2.1KViews0likes1CommentRe: SAP Logical System Setup for outbound IDOC
Hi @walkermic, I assume that you have already setup the Logical System through BD54. In WE20, you might want to create partner profile on the top of the logical system you created above. and also specify the partner type to ‘LS’ (stands for Logical system). Then, you need to specify the IDoc types you are going to send through the partner in the ‘Outbound Params’ . For each of them, you need to specify the IDoc types, as well as the IDoc port you are going to send to. The IDoc port should be defined in WE21 and should be configured to connect to the RFC destination in SM59 (where the program ID is provided) . Following is a screenshot of my partner profile. (Note I have Logical System and IDoc Port both named ‘SNAP1’): I’ve configured the partner profile so that it can send CREAMAS, HRMD_Am and MATMAS IDocs, and all of them would be sent to SNAP1 port. Hope this helps! Let me know if you have more doubts or queries. Thanks3.5KViews0likes0CommentsRe: AWS S3 Account "Cross Account IAM" benefit over using resource-based policy?
Hi Paul, The cross account IAM role is using a role inside the trusting account to delegate the role or user in trusted account. In this case, trusting role would be granted with all the permissions we want the trusted account to have, and we don’t need to explicitly expose a resource to some external account in the policy. Also, the cross-account role is more secure. The way it works is relying on the sts:AssumeRole API, the access it granted to the trusted role is a temporary one. Plus, it can be set with an external ID to provide an extra layer of security. This is especially beneficial for the case where the trusting account and trusted account are from different organizations The downside of cross-account role vs resource-based role is that, when we assume the role in the trusting AWS account, we are losing the original permissions we have in our own AWS account (since now we are acting as a role in trusting AWS account) As for the case using access-key ID and secret key, the goal of the cross-account effort above is to avoid sharing AWS credentials with different teams or organizations. Hope this helps!2.5KViews1like0CommentsRe: Kafka Consumer Snap
Hi, Based on your scenario, when first run the consumer snap, you may use a new group ID in the Consumer, and set ‘auto offset reset’ to earliest. This would let the Consumer to read from earliest at the first running (when initialize the new group). For ‘seek type’, you may set it to End, so that it would continue reading when resume. Hope it helps 🙂2.5KViews0likes2CommentsRe: Kafka Consumer Crash
The consumer can do auto-commit with an auto-commit interval, or it can commit manually using an Acknowledge Snap. When it restart again with the same consumer group ID, If we set “seek type” to End, it would resume from the last committed offset (251st document in your example). If set “seek type” to Begin, then it would restart from the 1st message of the topic. Hope it helps2.6KViews0likes0Comments