Introduction In this article, we’ll look at a solution that not only offloads your Salesforce image storage to Amazon Web Services (AWS), but also resizes and renders those images on demand. By offloading image storage to other solutions, your organization can free up Salesforce storage capacity. We’ll build off an example use case from Salesforce Field Service, but there are many other scenarios that can take advantage of these techniques. Having both a Salesforce org with Field Service installed and an AWS account are prerequisites for this article. Use case For our example, we will look at a fictional property maintenance company, Acme Maintenance. Acme manages property safety inspections on behalf of its clients. On-site inspectors use Salesforce Field Service to record their findings on their visits. As part of their site visits, inspectors take a lot of photographs on their mobile devices, and these are saved back to Salesforce. Acme would like to use these images in the Service Reports that they provide to their clients. Acme has discovered that with the number of site visits, multiplied by the number of images per visit and the size of those images (and on top of that they want to see reasonably-sized thumbnails of those images in Salesforce and surface them on Service Reports), they’re reaching the initial default file storage limits on Salesforce. While they could easily purchase more file storage within Salesforce, their Salesforce architect has suggested that off-platform storage may be more optimal. To solve this, we will look at interfacing with AWS for both image storage and image processing (resizing, cropping, orientation, and so on). AWS Services For our use case, we will look at one of the AWS reference architectures, the , and take advantage of to deploy it. In some ways, you can liken CloudFormation to Salesforce metadata—a way to deploy your resources in a declarative, script-based manner. Serverless Image Handler AWS CloudFormation The goes into greater detail, but in summary, we will leverage the following components: AWS documentation : load balancing the requests into the API Cloudfront : publishing the external API for use API Gateway : the serverless application that handles the image processing Lambda : storage of the original uploaded images and log files S3 (optional): If you use the image URL signature feature, then you can retrieve secrets for digital signing from here. Secrets Manager : if you require content moderation, smart cropping, facial recognition, and so on. Rekognition AWS configuration By using a CloudFront template, we don’t need to know a great deal about each of these AWS technologies; we simply have to go through a few configuration steps. Please note that in this example, we will take default settings rather than enable advanced features. It’s recommended that you read through the . implementation guide Create an S3 bucket for your images The first task is creating an S3 bucket to store our original image files. Choose a bucket name that is unique and lowercase, and then pick the region that is geographically closest to you. Check the box to “Block all public access.” Deploying the CloudFormation stack From the , click on to start deploying your own instance. Serverless Image Handler main page Launch in the AWS Console Before you start populating fields, be sure to select your AWS region in the top right corner of the screen on the CloudFormation page. Select the same region as your S3 bucket from the previous step. The path to the CloudFormation template should be pre-populated. Click . Next On the next screen, we specify a name for our stack and provide the name of our S3 bucket. Select “No” for the “Demo UI” and then click again. On the “Configure stack options” page, accept the default and click one more time. Next Next Finally, on the review page, click the button. As you refresh the page, you’ll see the progress of your stack build, which can take a few minutes. Then, you’ll see this: Create Stack As a final step, we need to go to the tab of the build and copy the value of the parameter, as we’ll be using this in our Salesforce build. Output ApiEndpoint Salesforce build Custom Objects and fields In Salesforce, we’ll start by creating a new custom object called , which will hold the information for any image attachments that relate to a Work Order. The key fields to note are , , and . When asked whether to add a related list to the Work Order page layout, be sure to select it. Work Order Attached Image Image RTF Original Image URL Resized Image URL Custom metadata Next, we need to create a Custom Metadata type to store our configuration settings. In Setup, search for and create a new type called with the custom fields shown below: Custom Metadata AWS Settings Once created, click the button and add the following three settings and save them. Manage AWS Settings For the image handler endpoint value, use the value from AWS CloudFormation. ApiEndpoint Named credentials Our next configuration item is for securely handling the access to AWS from Salesforce. In Setup, search for and create the following two credentials, substituting in your own AWS URL, region, and access key/secret from your AWS user. Be sure the fields are as shown in the screenshots, as this is used later in the code. Named Credentials Name Remote site settings In order for the images from AWS to appear in our Service Reports, we need to add the API endpoint as a trusted domain via Remote Site Settings. Triggers and classes Revisiting our scenario, image attachments from Field Service populate Salesforce as objects and associated supporting objects. Their object model looks like this: ContentDocument In order to capture newly attached images in the model, we can simply add a new Apex trigger to the object. This will allow us to reference both the attachment and the object it is attached to. ContentDocumentLink ContentDocumentLinkTrigger and ContentDocumentLinkTriggerHandler We build a that hands off processing to an Apex class for handling the trigger. ContentDocumentLinkTrigger Our trigger handler, , takes the list of new and collates them into a , keyed by the linked entity ID. It then inspects them to see the type of the linked entity, and—if it is a Work Order—adds them to a for processing. ContentDocumentLinkTriggerHandler ContentDocumentLinks Map Set This processing consists of building further collections to map an entity to associated records, before handing this data off to a Batch Apex class for processing asynchronously. ContentDocument WorkOrderAttachmentBatch The batch class for Work Order attachments, , iterates through the supplied collections, building up new records from the image filename and base URL of the AWS S3 bucket. WorkOrderAttachmentBatch WorkOrderAttachedImage A call is made to the class to get the crafted URL with which to call the Image API. Then, it constructs an RTF field with some simple HTML for rendering the resulting image. ImageRotationHandler Once the records have been created and saved, the list of image attachments passes to another batch class for the upload process. ImageRotationHandler The is a small class that handles the construction of a valid request to the Image API handler. It constructs the required JSON structure from the parameters, serializes it to a string, encodes it as Base64, and then appends this to the URL of the image handler endpoint. Formatting requests is included in the AWS template documentation under the . ImageRotationHandler Deployment section S3UploadHandler The final batch class, , handles the uploading of the attached images to our S3 bucket via a simple REST API call. S3UploadHandler Service Reports Now that we have our images on S3 and our custom object populated with our links to the images, we can now return to our Field Service use case. In our Salesforce setup, search for and click on . For demo purposes, we’ll create a new template. Service Report Templates On the template page, select from the Related Templates dropdown list. In the Body area of the template, add a new section element, based on the Work Order Attached Image object, as shown below: Work Order List Save the template and activate it. We’re now ready for testing. Create a new Work Order in Salesforce and save it. Then, upload an image file (in JPG or PNG format) to the Files section. Once the image has been uploaded, refresh the page. You should then see a new record in the related list. Clicking on the record should show a record similar to this, with the S3 image displayed: Work Order Attached Images From the Work Order, click the button. (It may be in the overflow menu dropdown): Create Service Report Select the Service Report template we created earlier and click the button. A preview of the Service Report PDF should render, complete with a thumbnail of your uploaded image in the appropriate section. Create PDF Conclusion In this article, we have successfully deployed a complete image handler solution to AWS, using a reference implementation from the AWS Solutions Library. We have implemented code with supporting objects and configuration in Salesforce to transfer uploaded image attachments to S3 and surface them within the platform and on Service Reports. With this architecture, we have the potential to reduce storage needs for image files within Salesforce. Outside of Field Service, there are many other use cases for reducing image storage needs. Another popular scenario, for example, is for Salesforce-powered web experiences in which users need to submit image files. Next Steps and Resources Here are some ideas for taking this architecture further: Implementing removal of the original Salesforce files once S3 has them Creating a custom Lightning Web Component to display the uploaded images Extending this implementation to support other file types, such as PDF documents Here are some useful links related to this implementation: AWS Serverless Image Handler The , which provides the image processing capability we use in AWS Sharp Library

Amazon

Salesforce

Next-Level Communication with WebRTC

An Intro to 10DLC, and Why Should You Care About It

I write about technology michael.bogan@gmail.com

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Microservices

Nominated for 2022 - HackerNoon Contributor of the Year - Devops

Nominated for 2022 - HackerNoon Contributor of the Year - Api

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Software

Too Long; Didn't Read

Make resilience your competitive advantage

Building an AWS Integration for Salesforce Image Handling

Building an AWS Integration for Salesforce Image Handling

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Threats to an Open API Ecosystem

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Threats to an Open API Ecosystem

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps