Ever found yourself stuck analyzing the exact messages generated by a Connector? You’re not alone! And there’s good news — with AWS Lambda, there’s a straightforward solution to make this process seamless.
When it comes to understanding customer data and crafting real-time marketing strategies, SAS Customer Intelligence 360 (CI360) stands out as a powerful platform for customer intelligence. It’s designed to leverage data to create personalized experiences — delivering right message at the right time and place. But let’s face it: the impact comes when CI360 is integrated with other systems — websites, mobile apps, communication channels, data sources, and more. Without these integrations, the system is like a sleek car with no tires and an empty tank.
The main use cases for the Connector include:
While there are many other possibilities, these two use cases are by far the most common in practice.
For the system to truly deliver its potential, integration is key. This is where the SAS CI360 Connector comes into play. It offers the powerful capability to integrate the system in a code-less manner. This feature enables seamless connections with third-party systems at virtually any stage or function in your marketing campaigns — whether it’s enriching data, sending communications, orchestrating processes, or much more.
While the code-less nature of the SAS CI360 Connector is undeniably convenient, it does come with some trade-offs. The most significant challenge is the limited visibility to what message exactly is being generated, which can pose substantial obstacles during the integration development process. As many would agree, troubleshooting and debugging are often the most time-consuming parts of any integration process. Imaging this: you’ve set up all the necessary configurations to integrate with a service, expecting everything to function seamlessly — only to find it doesn’t.
In an ideal world, the service on the other end provides detailed logging, allowing you to trace requests and quickly identify the issue. Unfortunately, this is rarely the case. More often than not, you’re left guessing, constantly adjusting parameters in an attempt to get even the simplest request to work. At this point, you may resort to tools like Postman, SoapUI, or cURL to manually replicate the request — and after some trial and error, you finally manage to craft a working request.
But then comes another challenge: how do you configure the Connector to replicate that exact request? Without visibility into the outgoing request generated by the Connector, you’re operating in the dark, with no clear way to ensure everything aligns correctly.
What’s the solution? A simple and practical approach is to create a mock service that accepts incoming requests and captures all their parameters, including headers and the request body. This provides complete visibility into how the Connector behaves, making the debugging process much more efficient and effective.
This is where AWS Lambda can offer a quick and effective solution. In this article, I’ll walk you through setting up AWS Lambda to capture, analyze, and troubleshoot issues with the CI360 connector. We’ll break everything down step-by-step, test the setup, and address potential challenges. So, grab a coffee, and let’s dive in!
Let’s focus on the two main use cases for the CI360 Connector:
Here’s the good news — configuring the Connector for both of these cases is almost identical.
To get started:
The inbound/outbound type of Connector simply sets the direction of the data. In our case, it doesn’t affect functionality, so with the configurations in place, we’re all set for now!
💡We leave the Access Point empty as the service used by the Connector is publicly accessible. Access Points are usually used when a proxy is needed to reach a service — for example, when the service is hosted on-premises and not publicly available.
One of the key advantages of AWS Lambda in our case is its permanent free tier — you get 1 million requests per month at no cost! And no, this isn’t one of those “first 12 months only” deals — this is forever.
If you’re curious about what other AWS services offer free-tier benefits, you can check out the complete list here.
The bottom line? Even with a relatively high number of Connectors, you’re unlikely to exceed the free tier limits.
❗Disclaimer: The AWS Lambda free tier offering limits are valid as of January 2025. However, they may change over time. For now, we can leverage the generous opportunities provided by AWS.
Now, without further ado, let’s dive into the fun part!
1. Log in to your AWS account
2. Go to the Lambda service:
3. Create new function “From scratch” and with latest Python runtime:
4. Add the code
Depending on your use case, the Lambda function’s code will differ:
5. Deploy and Test
Deploy the function, and test it with a simple event - really, any test event will do for now.
6. Set up a Function URL
To make the Lambda function callable via HTTPS:
While skipping authentication (using "NONE") is fine for testing purposes, it’s definitely not recommended for production environments!
7. Test the Function URL
At this point, you should be able to call the Lambda function using its URL:
8. Check the logs in AWS CloudWatch
Open AWS CloudWatch logs from Monitor tab:
At the very least, you should see one log stream:
For example, accessing the Function URL via your browser will generate headers that include details like browser type, version, operating system, and more.
❗If you don’t see any log streams or logs, double-check your Lambda function permissions. Make sure your policy includes access to create log groups, create log streams, and put logs:
Now your AWS Lambda setup is complete! From here, we can move on to creating Endpoints in CI360 Connectors and testing them.
Let’s start by creating the endpoints for your Connectors.
1. Activate the Connector and Add the endpoint
Toggle the Connector to Active, then click “Add endpoints”:
2. Configure the Endpoint
Enter the Function URL you created earlier in AWS Lambda:
3. Save and test
After saving, go to the Test Endpoint section to begin testing:
Now comes the exciting part — testing it!
Click Run test, and you should see the response message you defined in the Lambda code:
The same process applies to the Dropdown List Lambda function, but the response will look a little different:
Now let’s verify what’s happening behind the scenes. Open AWS CloudWatch, where you should find logs similar to this:
Congratulations — your configuration is complete! With everything set up, you can now start debugging the requests generated by CI360.
❗Chrome Developer Tools
You might be wondering, “Why not just use Chrome Developer Tools to trace requests?”
Unfortunately, this approach won’t work here. The requests you capture in your browser don’t directly reflect the Connector behavior in CI360, as the actual request is generated in CI360 Cloud. What you see in Developer Tools is simply a task sent from your browser to the Cloud to create the proper request and invoke the Endpoint URL you provided.
To illustrate how the request process works, let’s create a simple dummy test.
1. Add inline parameters and authentication
Append an inline parameter to the Function URL and use a dummy Basic Auth:
2. Add headers and standard parameters
Add a header and an additional parameter:
3. Define the Custom Request Body
You can define a request body to include custom data:
💡Even though the interface says “Enter the JSON,” it will accept just about anything you put there.
4. Observe the generated request
Run the test and review the resulting request. I’ve highlighted the parts of the request that were directly influenced by our Endpoint configuration.
{
"version": "2.0",
"routeKey": "$default",
"rawPath": "/",
"rawQueryString": "inline-param1=value1¶meter2=value2",
"headers": {
"x-b3-parentspanid": "XXX",
"x-amzn-tls-version": "TLSv1.3",
"x-datadog-sampling-priority": "1",
"x-datadog-origin": "rum",
"x-b3-sampled": "0",
"x-forwarded-port": "443",
"authorization": "Basic bG9naW46cGEkJHcwcmQ=",
"x-amzn-tls-cipher-suite": "TLS_AES_128_GCM_SHA256",
"x-datadog-parent-id": "XXX",
"tracestate": "dd=s:1;o:rum;p:XXX",
"ci360-connector-target-authorization": "Basic bG9naW46cGEkJHcwcmQ=",
"host": "XXX.lambda-url.us-east-2.on.aws",
"content-type": "text/plain;charset=UTF-8",
"header1": "header-value1",
"x-forwarded-proto": "https",
"accept-language": "en-US",
"ci360-connector-proxy-url": "https%3A%2F%2Fextapigwservice-prod.ci360.sas.com%2FmarketingGateway%2Fconnectors%2FproxiedTargetInvocations",
"x-datadog-trace-id": "XXX",
"x-forwarded-for": "XXX",
"accept": "application/json, application/cbor, application/*+json, */*",
"ci360-tenant-moniker": "XXX",
"x-amzn-trace-id": "XXX",
"x-b3-traceid": "XXX",
"x-b3-spanid": "XXX",
"user_id": "XXX=",
"traceparent": "XXX",
"tenant_moniker": "XXX",
"accept-encoding": "gzip,deflate",
"user-agent": "CI360"
},
"queryStringParameters": {
"inline-param1": "value1",
"parameter2": "value2"
},
"requestContext": {
"accountId": "anonymous",
"apiId": "XXX",
"domainName": "XXX.lambda-url.us-east-2.on.aws",
"domainPrefix": "XXX",
"http": {
"method": "GET",
"path": "/",
"protocol": "HTTP/1.1",
"sourceIp": "XXX",
"userAgent": "CI360"
},
"requestId": "XXX",
"routeKey": "$default",
"stage": "$default",
"time": "13/Jan/2025:16:10:19 +0000",
"timeEpoch": 1736784619409
},
"body": "custom-param=value",
"isBase64Encoded": false
}
💡If logs are not appearing in CloudWatch, experimenting with different request types (e.g., GET, POST, PUT, etc.). While this doesn’t change the message content, it can help bypass caching mechanisms that might be active at various levels.
Finally, let’s verify the value of the Authorization header which we configured as basic authentication:
💡Quick recap on Basic Auth:
When a login and password are specified, the request automatically includes an Authorization header with a value in the format:
Basic <base64-encoded-string>
Here’s how it works:
For example, decoding the string from the Authorization header of the message reveals:
login:pa$$w0rd
Exactly as configured during the Connector setup.
</aside>
Everything seems to be working perfectly!
Debugging the SAS CI360 Connector may seem complex at first, but as we’ve demonstrated, leveraging AWS Lambda makes it a straightforward and effective process. With connectors configured and Lambda properly set up, you gain a robust tool to capture, analyze, and refine CI360 Connector requests, ensuring smooth integration implementation process.
Key takeaways:
Now it’s over to you!
If we zoom out and take a broader view, debugging SAS CI360 Connectors is just one piece of the larger marketing automation puzzle. At T1A, we specialize in end-to-end implementation projects, ensuring tools like SAS CI360 are used to deliver maximum value for your business.
Whether you need help resolving connector issues, streamlining workflows, or building end-to-end integration strategies, we’re here to support you.
Ready to take your marketing technology to the next level?
Contact us today to explore how we can help drive your business forward.
Tutorial: Building a SAS Customer Intelligence 360 Connector Function
