Category: Aws

How to use Handlebars in an AWS Lambda function

February 14th, 2023
Reading Time: 2 minutes
Handlebars is a popular templating library that can be used to generate dynamic HTML pages. You can use Handlebars in an AWS Lambda function by following these steps:
1. Create an AWS Lambda function: To start, you need to create an AWS Lambda function in which you will write your code.
2. Install Handlebars: To use Handlebars in your Lambda function, you need to install it as a dependency. You can do this by adding handlebars to the dependencies section of your project’s package.json file and running npm install.
3. Load the Handlebars library: In your Lambda function code, you need to load the Handlebars library. You can do this by including the following code:
```
const handlebars = require('handlebars');
```
1. Compile a Handlebars template: To use Handlebars, you first need to compile a Handlebars template that specifies the structure of your HTML page. You can do this by using the following code:
```
const template = handlebars.compile(`
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>Hello, {{name}}!</h1>
  </body>
</html>
`);
```
1. Render the template: To render the template, you need to pass in an object that provides the values for the template’s variables. You can do this by using the following code:
```
const html = template({ name: 'AWS Lambda' });
```
1. Return the generated HTML: Finally, you need to return the generated HTML from your Lambda function. You can do this by including the following code:
```
exports.handler = async (event) => {
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'text/html' },
    body: html,
  };
};
```
1. Deploy the function: After you have written your code, you need to deploy your Lambda function to AWS. You can do this using the AWS CLI or the AWS Management Console.
These are the basic steps for using Handlebars in an AWS Lambda function. You can customize this code to meet the specific needs of your application.
Share this:
Twitter
LinkedIn
Reddit
Email
Telegram
WhatsApp
Like this:
Like Loading…

How to write to S3 bucket from Lambda function

January 29th, 2023

Reading Time: 2 minutes

AWS Lambda functions are a great way to automate certain tasks and processes in the cloud. They can be triggered by events, such as a file upload to an S3 bucket or a message sent to an SNS topic, allowing you to execute some code in response.

In this post, we’ll show you how to write data to an S3 bucket from a Lambda function. This can be useful for a variety of tasks, such as archiving log files or uploading data to a data lake.

S3 (Simple Storage Service) is Amazon’s cloud storage solution that allows you to store and access data from anywhere in the world. Writing to an S3 bucket from a Lambda function is a simple way to store and access data in the cloud.

In this post, I’ll walk you through how to write to an S3 bucket from a Lambda function. We’ll use the AWS SDK for Node.js to access S3.

Take this example as a starting point. This is not a production-ready code, probably some tweaks for permissions will be necessary to meet your requirements.

AWS resources we need

Lambda Function
S3 Bucket
Lambda Role
Bucket Policy

The Lambda function

const AWS = require("aws-sdk");
const s3 = new AWS.S3({
    region: "us-east-1",
});
let response;

exports.lambdaHandler = async (event, context) => {
    try {
        console.log(event);
        const params = {
            Bucket: process.env.MY_BUCKET,
            Key: 'test-file.txt',
            Body: "test content"
        }
        console.log('writing to s3', params);
        const result =  await s3.putObject(params).promise();
        console.log(result);

        response = {
            'statusCode': 200,
        }
    } catch (err) {
        console.log(err);
        return err;
    }

    return response
};

The SAM template

For the sake of simplicity, we are going to use Principal: “*” which makes your bucket 100% public!

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  Sample SAM Template for Lambda and S3
Parameters:
  Environment:
    Type: String
    Description: Environment name. Example, staging
Resources:
  MyLambda:
    Type: AWS::Serverless::Function
    DependsOn:
      - "MyBucket"
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs12.x
      Environment:
        Variables:
          MY_BUCKET:
            Ref: "MyBucket"
      Role:
        Fn::GetAtt:
          - "MyLambdaRole"
          - "Arn"
    Tags:
      Name: !Sub "${Environment}-my-test-lambda"

  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "${Environment}-my-test-bucket"

  MyBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      PolicyDocument:
        Id: BucketPolicy
        Version: 2012-10-17
        Statement:
          - Sid: AccessAll
            Action: s3:*
            Effect: Allow
            # Beware: this makes your bucket public!
            Principal: "*"
            Resource: !Join
              - ''
              - - 'arn:aws:s3:::'
                - !Ref MyBucket
                - /*
      Bucket: !Ref MyBucket

  MyLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Action: "sts:AssumeRole"
            Principal:
              Service:
                - "lambda.amazonaws.com"
        Version: "2012-10-17"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: MyLambdaPolicy
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action: "s3:*"
                Resource:
                  - Fn::GetAtt:
                      - "MyBucket"
                      - "Arn"
            Version: "2012-10-17"

As a good practice, always receive the environment as a parameter. This way, all your resources will be easier to identify.

Deploy

Build our lambda and template. This will check also the syntax of your template

$ sam build

Only for the first time run and follow the steps:

$ sam deploy --guided

The second time and so on you can execute:

$ sam deploy --no-confirm-changeset

Clean up your test AWS resources. Delete unused lambdas, buckets, etc to keep your account organized and the most important: no extra costs

Resources

Mock AWS SDK with Jest in TypeScript

January 29th, 2023
Reading Time: 2 minutes

The AWS SDK is an incredibly powerful tool for managing resources in the cloud. But what if you want to use the SDK without having to deploy your code to AWS?

Mocking the SDK with Jest and TypeScript is a great way to quickly and easily test code that interacts with AWS services. By mocking the SDK, you can simulate requests and responses to ensure that everything works as expected.

This tutorial will walk you through how to create a mock of the AWS SDK and how to use it with Jest and TypeScript

When writing automated tests for applications that use Amazon Web Services (AWS) APIs, it can be difficult to test code that interacts with the AWS SDK. In order to make testing easier, you can use Jest in combination with TypeScript to mock the AWS SDK and simulate responses from the AWS service. This makes it possible to create reliable tests for your application without actually calling AWS APIs.

Advantages of mocking the AWS SDK
- Avoid hitting AWS services will make you save so much money, especially if you have thousands of tests. Even if you use Localstack, your project’s configuration from checking out the code until you run it will take more time.
- You tests will run faster
Disadvantages of mocking the AWS SDK
- Slow down development process
- Mocks for almost every scenario, otherwis,e it will call the real code (what we want to avoid)
Let’s see an example of how to mock the AWS SDK with Jest and TypeScript

The following code mocks two methods of SQS: receiveMessage and deleteMessage. If your code uses more methods of the AWS SDK you will have to mock all of them. Otherwise, your tests will call the real code.
```
import AWS from "aws-sdk";
jest.mock("aws-sdk");
const mockAws = AWS as jest.Mocked;

const mySQSMock = {
  receiveMessage: () => {
    return {
      promise: () =>
        Promise.resolve({
          Messages: [{ Body: "test" }],
        }),
    };
  },
  deleteMessage: () => {
    return {
      promise: () => Promise.resolve(),
    };
  },
};

describe("My test suite", () => {
  beforeAll(() => {
    mockAws.SQS.mockImplementation(jest.fn().mockImplementation(() => mySQSMock));
  });

  test("My test", async () => {
    // TBD
  });
});
```
Share this:
Twitter
LinkedIn
Reddit
Email
Telegram
WhatsApp
Like this:
Like Loading…

Handlebars and AWS Lambda example

January 29th, 2023

Reading Time: < 1 minutes

Handlebars is an easy-to-use templating language that helps you create rich and dynamic websites. With its intuitive syntax and powerful features, it’s a great choice for quickly and easily building powerful web applications.

Combining Handlebars with AWS Lambda can make your life even easier. AWS Lambda is a serverless compute service that can run code without needing to provision or manage servers. By using Handlebars alongside AWS Lambda, you can quickly create websites or applications without having to write a lot of code.

      
const handlebars = require('handlebars');
const {promises: {readFile}} = require("fs");

let templateSource;

const renderToString = async (data) => {
    if(!templateSource) templateSource = await readFile('./views/content.hbs', {encoding:'utf8', flag:'r'})
    const template = handlebars.compile(templateSource);
    return template(data);
}

let response;
let html;
const lambdaLoadedDate = new Date().toISOString();

exports.lambdaHandler = async (event, context) => {
    try {
        const now = new Date().toISOString();
        html = await renderToString({title: 'im the title', now: now, lambda_date: lambdaLoadedDate});
        response = {
            statusCode: 200,
            headers: {
                'Content-Type': 'text/html',
            },
            body: html
        }
    } catch (err) {
        console.log(err);
        return err;
    }

    return response
};

AWS AppFlow error conflict executing request connector profile is associated with one or more flows

February 14th, 2022
Reading Time: < 1 minutes

AWS AppFlow is a fully managed cloud integration solution for moving data between SaaS applications. It enables customers to model and configure flows to synchronize data between applications with just a few clicks. When setting up a flow, customers may encounter an error that says “conflict executing request connector profile is associated with one or more flows”.

This error occurs when a connector profile used in a flow is associated to one or more other flows either in the same or another account. While the dependability of the flow connector

Let’s say you have a Salesforce connector (it is valid for any other available) and the token expired. The only way so far is to delete and recreate the connection again. Would be nice to keep the same connection and run the handshake again but it is impossible nowadays.

If we try to delete a connector from the AWS console and it is associated with one or many flows, it will display this error:
```
Conflict executing request: Connector profile: xxxxxxx is associated with one or more flows. If you still want to delete it, then make delete request with forceDelete flag as true. Some of the associated flows are: [xxxxx, xxxxxx]
```
The trick is to delete the connector from AWS CLI thus:
```
aws appflow delete-connector-profile --connector-profile-name xxxxxxx --force-delete
```
After that you will be able to recreate the connection again

More useful AWS CLI commands for AppFlow
```
aws appflow describe-flow --flow-name xxxxxx
aws appflow list-flows
aws appflow describe-connectors --connector-types Salesforce
```
Resources
- AppFlow CLI docs
Share this:
Twitter
LinkedIn
Reddit
Email
Telegram
WhatsApp
Like this:
Like Loading…
AWS suspended error AppFlow

February 11th, 2022
Reading Time: 1 minute
If you’re an AWS user, you’ve likely encountered the dreaded “AWS suspended error” in AppFlow at some point. This error can result from various issues, but if you are using a Salesforce connector, it can be due to the Salesforce daily limit being exceeded. So you consumed all your daily API requests for the day.

You’re not alone if you’ve experienced this error. Many AWS users encounter this message while trying to retrieve data or update resources. So, what can you do if you run into this error?

AWS AppFlow suspended status error is sown for many reasons. You have to click on the Suspended word in the AWS console to see the extended error. Another option is to see it through the CLI

The error

This is an example error you could get:
```
The flow has been suspended due to an error in Salesforce when subscribing to the event. Here's the detailed error message: The request failed because the service Salesforce returned the following error: Details: Subscribing to topic /data/xxxxxxxx__ChangeEvent with replayId -1 failed due to com.amazon.sandstonebridge.connector.exception.ClientSubscriptionException: Cannot subscribe to topic /data/xxxxxxxxx__ChangeEvent, replay from -1, with error 403::Organization total events daily limit exceeded (Service: null; Status Code: 400; Error Code: Client; Request ID: xxxxxxxxxx; Proxy: null).
```
And this is the main reason:

Organization total events daily limit exceeded

How to fix it the Salesforce daily limit exceeded error

Option 1

Just wait a couple of hours and reactivate the flow again. The main reason is Organization total events daily limit exceeded which means we reached our Salesforce daily limit for events

Option 2

Another option is to increase that limit (through Salesforce support) but that will depend on many reasons. However, you should find the root cause, especially if that limit exceeded doesn’t make sense with your Salesforce implementation.
Share this:
Twitter
LinkedIn
Reddit
Email
Telegram
WhatsApp
Like this:
Like Loading…
Conflict executing request: Connector profile: xxxxxx is associated with one or more flows

November 23rd, 2021
Reading Time: < 1 minutes
Error

Conflict executing request: Connector profile: xxxxxx is associated with one or more flows. If you still want to delete it, then make delete request with forceDelete flag as true. Some of the associated flows are: [flow1, flow2,…]

Run this from terminal (replace the xxxxx):

aws appflow delete-connector-profile –connector-profile-name xxxxxxx –force-delete

Some others useful commands

aws appflow describe-flow –flow-name xxxxxxx

aws appflow list-flows

aws appflow describe-connectors –connector-types Salesforce

Photo by JC Gellidon on Unsplash
Share this:
Twitter
LinkedIn
Reddit
Email
Telegram
WhatsApp
Like this:
Like Loading…
Invalid request provided: AWS::AppFlow::FlowCreate – Salesforce integration

November 19th, 2021
Reading Time: < 1 minutes
We could see this error when deploying a stack in AWS that contains an App Flow block. If we are doing through Cloudformation it’s possible we have added a new mapping to a field that doesn’t exist in Salesforce.

Let see an example of error

In this case, Field1__c and Field2__c are being mapped in App Flow but those do not exist in Salesforce or at least App Flow doesn’t have permissions to access them.

Resource handler returned message: “Invalid request provided: AWS::AppFlow::FlowCreate Flow
```
request failed:

[

Task Validation Error: The following connector fields are not

supported: [Field1__c, Field2__c]

The task sourceConnectorType is FILTERING and the task operator is PROJECTION,
Task Validation Error:

The following connector fields are not supported: [Field1__c]

The task sourceConnectorType is MAPPING and the task operator is NO_OP,

Task Validation Error: The following connector fields are not supported:

[Field2__c] The task sourceConnectorType is MAPPING and the task operator is NO_OP

]

(Service: Appflow, Status Code: 400, Request ID: xxxxxx-xxxx-xxxxx-xxxxx-xxxxxxx,
Extended Request ID: null)" (RequestToken: xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxxxx,
HandlerErrorCode: InvalidRequest)
```
Verification checklist
- Make sure the field exists
- Make sure you don’t have a typo in the field name
- Make sure the user used for the OAuth connection has necessary permissions. You could check Field-Level security or an existing permission set
- Try to recreate the connection and deactivate/activate the App Flow
Share this:
Twitter
LinkedIn
Reddit
Email
Telegram
WhatsApp
Like this:
Like Loading…
AppFlow Salesforce: how to sync up relationships

November 10th, 2021
Reading Time: < 1 minutes
Using AppFlow, you can easily move data between Salesforce and other cloud-based systems such as Microsoft Dynamics, Oracle, or SAP. With AppFlow, you can automate the movement of data between these systems, which in turn means you can save time and energy.

One object at a time

At the time of writing this post, it’s not possible to sync up relationships from Salesforce to AppFlow. Only basic types such as strings or numbers can be passed through AppFlow which means that look-up fields will be ignored. There’s a way you can do it with some work from using the Salesforce out-of-the-box Process Builder or Flows tool, a custom object and some lines of Apex code.

The trick

We will need these three things to send out our related fields through AppFlow
- A custom object
- An Apex class
- Process Builder
The custom object

This custom object will hold all three attributes to be synchronized. It will be our DTO(Data Transfer Object)

The Apex class

It will gather all the information we need and instantiate our DTO. Once inserted, Change Data Capture will take over the control to send our data to AppFlow

The flow built using Process Builder or Flows

It will call our Apex class under the conditions we want. It can be a “just execute every time I save an Account ” or with more complex rules
Share this:
Twitter
LinkedIn
Reddit
Email
Telegram
WhatsApp
Like this:
Like Loading…

How to trigger a Lambda Function from S3

July 27th, 2021

Reading Time: 2 minutes

If your application requires you to be able to trigger a Lambda function from S3, it is possible to do so using the Amazon Simple Storage Service (Amazon S3). With Amazon S3, you can set up an event notification on an Amazon S3 bucket that will send a notification to an AWS Lambda function when an object is created or deleted. In this post, we will walk through the steps to trigger a Lambda function from S3.

Sometimes we need to let a Lambda know when a new file was created in an S3 bucket. That’s can be the case when we have a data lake and we want to process those files. But beware, when we talk about a data lake, we mean a huge amount of data so we shouldn’t start processing immediately a file is written since our capacity can be limited. In that case, we should use a queue mechanism but that is out of the scope of this post so Let’s concentrate on our specific problem: trigger a Lambda from S3.

We could do this from the console using point and click but as a good practice, let’s automate this provisioning with Cloudformation. This way we will be able to move our code across different accounts and deal with environments easily.

The Cloudformation approach can be slow at the beginning but once you get familiar with it, you will accelerate your dev process. Another big advantage of Cloudfromation is versioning. Since our output is a yml file, it can be easily add it to a github repo. Thus, tracking changes becomes a piece of cake. However, you may resolve your problem first from the console and then translate it to Cloudformation

Let’s do it step by step, building small pieces of Cloudformation components, deploy them and then put all together in one file.

Have in mind this is not a production-ready solution. Probably you will have to make your own customizations so take this as a starting point.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  lambda-s3-trigger

  Sample SAM Template for lambda-s3-trigger

Globals:
  Function:
    Timeout: 3

Parameters:
  Environment:
    Type: String
    Description: Environment name. Example, staging, dev, prod, etc.

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs12.x
      Role:
        Fn::GetAtt:
          - "MyRole"
          - "Arn"
    Tags:
      Name: !Sub "${Environment}-my-function"


  MyRole:
    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: AccessToS3Notifications
          PolicyDocument:
            Version: 2012-10-17
            Statement:
              - Effect: Allow
                Action:
                  - 's3:GetBucketNotification'
                  - 's3:PutBucketNotification'
                  - "s3:GetObject"
                Resource: !Sub 'arn:aws:s3:::${AWS::AccountId}-${Environment}-my-bucket'

  MyBucket:
    Type: AWS::S3::Bucket
    DependsOn:
      - MyFunction
    Properties:
      # the bucket name has the account as a prefix since it has to be unique globally at AWS level
      BucketName: !Sub "${AWS::AccountId}-${Environment}-my-bucket"
      NotificationConfiguration:
        LambdaConfigurations:
          - Event: 's3:ObjectCreated:*'
            Function: !GetAtt MyFunction.Arn

  PermissionForEventsToInvokeLambda:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt MyFunction.Arn
      Action: "lambda:InvokeFunction"
      Principal: "s3.amazonaws.com"
      SourceAccount: !Ref 'AWS::AccountId'

Build and deploy:

$ sam build
$ sam deploy --guided

Category: Aws

Share this:

Like this:

AWS resources we need

The Lambda function

The SAM template

Deploy

Resources

Share this:

Like this:

Advantages of mocking the AWS SDK

Disadvantages of mocking the AWS SDK

Let’s see an example of how to mock the AWS SDK with Jest and TypeScript

Share this:

Like this:

Share this:

Like this:

More useful AWS CLI commands for AppFlow

Resources

Share this:

Like this:

The error

How to fix it the Salesforce daily limit exceeded error

Option 1

Option 2

Share this:

Like this:

Error

Some others useful commands

Share this:

Like this:

Share this:

Like this:

One object at a time

The trick

The custom object

The Apex class

The flow built using Process Builder or Flows

Share this:

Like this:

Share this:

Like this: