You can also watch Salesforce Keynote highlights of the event.

Einstein 1 Platform

Salesforce announced the Einstein Trust Layer which seems to be their focus of what’s behind the Einstein 1 Platform. This makes sense since Salesforce’s core value is trust, this product might be the core that separates Salesforce AI functionality from other solutions. I’m very interested in learning more about each specific part they announced, like data masking, zero retention, and dynamic grounding. We should know what prompt is sent to the LLMs, how the CRM and other enterprise data are used in prompts (for dynamic grounding), and how exactly zero retention is implemented in each LLM provider (e.g. OpenAI). It’s great seeing a slide explaining Einstein Trust Layer makes sure the prompt is not used by the LLMs to train their model, but I think it’s important to challenge these claims and ask questions 🙂.

It would also be interesting to try and connect external models or cloud services, like LAMA, Amazon SageMaker or Azure OpenAI service. This way we take advantage of the middleware inside the Trust Layer that guarantees security and input moderation. As partners, we have access to some Salesforce events and I definitely recommend attending “AI & Einstein Office Hours” on Tuesdays. Claudio Moraes from Salesforce is sharing extremely useful information about Einstein GPT, the details of the Trust Layer, and more AI topics!

Here are some interesting videos that Salesforce has already done, explaining further the Einstein Trust layer and Einstein GPT:

• Build The Future of Business with Einstein GPT
• Salesforce AI day: Calling All Trailblazers

Einstein Copilot

Well… as you know, 2023 was the year of copilots. Salesforce is also taking advantage of that wave and has introduced Einstein Copilot and Einstein Copilot Studio. This looks a lot like what they announced some time ago, Einstein GPT.

I think it’s great that Einstein is more integrated across various products, especially Commerce and Service Cloud. Facilitating the manual work that the business has to do in various merchandising operations only brings benefits.

Generative AI in SFCC Page Designer

About generative Page Designer that they announced, we could simply say “yup, LGTM” and simply use it… but I do have some questions that need answering 😅. The demo they showed looks good and it’s probably a feature that brings tons of value to a lot of customers. But watching it made my mind go through endless questions. At first glance it’s amazing, we could really speed up the development of new components. UI/UX designers, merchandisers, and other business profiles can ask an AI to generate a component without a dev.

Still, I think as a developer we need to understand what is happening underneath, where is the generated code saved, what is the prompt used to generate the component, does it have context of the whole codebase, etc. This might have been the most interesting announcement and something to watch out for. However, we must also criticize and understand the limitations of this technology. In the demo they created, the user enters a brief description of the layout and content they want in the component, then the code is generated in React (it also supports ISML). I don’t believe React is actually used in SFRA, only in the Headless architecture, so their demo raises some questions about how it works underneath.

But anyway, I look at this as if it were v0.dev, that is, the 1st version or v0 of a component. The business or UI designers can experiment and generate several iterations of a component with this functionality, and then paste the generated code into a user story in a scrum board for a developer to retrieve. But it would just be a v0, something to be iterated over before going to production. I don’t think we’re ready yet for generative AI to know the website’s design system, know what caching considerations to apply to the component, have context about the logic behind add to cart if it’s integrated with a 3rd party vendor, etc. But we could also be optimistic and in all the use cases where gen AI struggles, it’s only going to improve.

Note: Page Designer’s Generative AI is expected to launch in beta in February 2024.

Commerce Concierge

Salesforce also announced a new product that is in beta called Commerce Concierge. Basically, the product is centered on the concept of Conversational Commerce. We can integrate our e-commerce website into WhatsApp as if it were one of those ChatGPT plugins that allow you to make purchases on a website.

For example, a customer takes a photo of a product and asks if there is a store with stock so they can make the purchase. If the customer happens to make a purchase on WhatsApp, the bot can respond with new product suggestions trying to effectively cross-sell. Technically, Commerce Concierge uses APIs from Commerce Cloud, Service Cloud, Data Cloud, and the AI ​​layer with Einstein GPT. At the moment I think it will only be launched for Commerce B2B and not B2C. This makes sense to me since it is easier to integrate Clouds that are already within the Salesforce Core Platform… but I hope we have this for SFCC in the future 🙂. I also think it will be possible to expand to more touchpoints, not just WhatsApp.

It’s also important to be aware of new attack vectors. Innovation is awesome and we should strive for more and tinker with these new capabilities. However, innovation can bring new security concerns. In these apps that will be available straight from WhatsApp or our storefront, we should be aware of Prompt injection, Jailbreaking, etc.

Conclusion

It was a great event and I can’t wait to get my hands on some Einstein GPT features for B2C! Hopefully, there will be more features on SFCC that are only available for customers of B2B and D2C 🙏. For example generating product descriptions or commerce intelligence 🙂.

Generating product descriptions with Einstein seems to be really useful if we have a batch of new products that we want to launch. It would be great to have this available in an HTTP API, so that we could integrate this functionality in use cases where our PIM (Product Information Management) is a custom system, or just use them in SFCC. Again… for now some features are only on B2B and D2C side of the commerce products (the ones integrated in Salesforce Core Platform).

If you’re interested in learning about session management in SFCC read this blog post.

The post Dreamforce 2023 Highlights appeared first on Blog IT.

We have a great feature available to us in Salesforce Commerce Cloud (SFCC) called SEO meta tag rules. This is a module inside SEO in Business Manager (BM). However, currently there is only support for PDP/PLP pages made in page designer that support these meta tag rules.

In this blog post we’ll see how to support SEO meta tag rules for all pages made in page designer.

The problem

Before going any further, I want to mention some disclaimers. At the time of writing this, not all pages in page designer support this. This could be added to SFCC and be directly supported without custom development. I posted this idea as a feature enhancement for Salesforce in IdeaExchange.

With that said, let’s take a step back and understand the problem.

The SEO experts on a business operate mostly on the SEO meta tag rules BM module. If they need a more granular level of SEO customization, most System Objects (e.g. Products, Content Assets, Categories) of SFCC support SEO fields like pageUrl, pageTitle, pageDescription. SEO experts can define rules that act as fallbacks, and then if some merchants don’t define these fields for particular categories or pieces of content. You still have some meta tags being added to the page by these rules.

Now, even though this feature supports many types of pages, like home page, product pages or product listing pages. It doesn’t support all types of Page Designer (PD) pages. You can also take a look at the Page class, and check that it doesn’t have the pageMetaTags field like the Content class does. Page Designer pages are very similar to Content Assets, in the sense that underneath, these pages are persisted as the same content objects on the SFCC’s database. But there are still differences, the support for meta tag rules is one of them.

Ultimately, these differences makes it harder for merchants or SEO experts that want to leverage the same functionality available on the rest of the site.

Now that you have a better understanding about the problem, let’s shift our focus into a solution.

The solution

Content Assets

The whole premise of this solution is that it’s supported by the SEO meta tag rules module of BM. In this module we have support for the following:

• Homepage
• Product pages
• Content Detail pages
• Content Listing pages

The only one that fits well with a page designer page is Content Detail page. Meaning we’ll create content assets as a way to support these SEO rules for Page Designer. Each page can have it’s corresponding content asset, where the content ID follows a naming convention like “-seo”. This way in Page.js you can get the meta tags for that page, through that content asset. Here is an example of the Page-Show extension:

server.prepend("Show", function (req, res, next) {
   var PageMgr = require('dw/experience/PageMgr')
   var ContentModel = require('*/cartridge/models/content')
   var pageMetaHelper = require("*/cartridge/scripts/helpers/pageMetaHelper")

    var page = PageMgr.getPage(req.querystring.cid);
    if (page != null && page.isVisible()) {
        var pageContent = ContentMgr.getContent(page.ID + "-seo")
        if (pageContent) {
            var content = new ContentModel(pageContent, "content/content")

            pageMetaHelper.setPageMetaData(req.pageMetaData, content)
            pageMetaHelper.setPageMetaTags(req.pageMetaData, content)
        }
    }
    next()
})

Now you don’t need to create a content asset for every since page from PD. For example, if you business doesn’t use the syntax ${Content.pageTitle} in your meta tag rules, or any expression regarding the object Content. Then in that case you could simply create one content asset for each folder the business wants to have. You might be wondering why I’m mentioning folders and how they fit in the solution, so let’s take a deeper look.

Folders

Folders are the way you can group multiple pages, and make all of them inherit the same meta tag rules. Once a folder is created, the business can use it in the SEO meta tag rules module inside BM. Imagine you have a group of pages that are part of the same marketing campaign. As an SEO expert, of course you’d like to have page titles, descriptions, open graph and other meta tags for all of them. But maybe the content team hasn’t reached the maturity level to configure this for every since page. So you create a meta tag rule, acting as a fallback in case the content team doesn’t configure some pages.

So far the solution revolves around the business creating manually: folders, assigning them to pages and creating content assets for every page (in case they want to leverage page properties) or every folder. I believe we can improve on this solution, so let’s jump in to some automation!

Automation

This is a critical step, since having all this manual work doesn’t make sense for business people. As engineers we can do better and automate the creation of these content assets. We can develop two different pieces that play together:

• A job to ensure every page from Page Designer, has it’s associated content asset and all the rest
• A new BM module to automate folder creation, specifically creating multiple folders

Let’s go through the job first, its responsible to update the content assets associated with each page. This means creating that content asset if it doesn’t already exist, then assign it to the same folders as the page. To implement this job you need:

1. Get the list of all Page Designer pages
2. Iterate through all pages
3. For each page, create the content asset and assign the appropriate folders

Here is a code snippet (in ES6) representing a possible implementation:

const libraryGateway = require("*/cartridge/scripts/gateways/libraryGateway")
const pagesList = getAllPageDesignerPages()

pagesList.forEach(page => {
    const contentId = `${page.ID}-seo`
    const result = libraryGateway.createContentAsset({
        id: contentId,
        pageTitle: page.pageTitle
    })
    if (result.error) {
        throw new Error("Error creating content asset")
    }
    
    page.folders.forEach(folder => {
        const result = libraryGateway.assignContentAssetToFolder(contentId, folder.ID)
    })
})

function getAllPageDesignerPages() {
    const ContentSearchModel = require("dw/content/ContentSearchModel")
    const apiContentSearchModel = new ContentSearchModel()
    const libraryID = "someId"
    
    apiContentSearchModel.setRecursiveFolderSearch(true)
    apiContentSearchModel.setFilteredByFolder(false)
    apiContentSearchModel.setFolderID(libraryID)
    
    apiContentSearchModel.search()
    const contentSearchResultIterator = apiContentSearchModel.getContent()
    const count = Number(apiContentSearchModel.getCount())
    
    const pages = []
    if (contentSearchResultIterator && count > 0) {
        while (contentSearchResultIterator.hasNext()) {
            const contentResult = contentSearchResultIterator.next()
            if (contentResult?.page) {
                // transform some contentResult fields to other types...
                pages.push(contentResult)
            }
        }
    }
    
    return pages
}

In the implementation above, getting all pages from page designer is done through the ContentSearchModel API. Although this works, it’s not ideal in my opinion since these pages are required to be searchable (a setting on all pages) and online. If they aren’t, they won’t be on the Content index. Which seems to be the only way to get all PD pages on the site. To create content assets and assigning them to folders, we delegate that responsibility to the libraryGateway module. To implement this module we need to use OCAPI.

OCAPI

We can use OCAPI Data APIs to create content assets/folders and assign content assets to folders. While researching I tried finding another way, but I didn’t find anything easier. The Salesforce Commerce API (dw library accessible server-side) doesn’t seem to have APIs for these operations. I didn’t find any pipelets or jobs steps that do this either… perhaps by exporting the content library, then creating a custom job that reads that file, edits it with the new content objects, and finally runs a job step to import that edited file.

Interacting with OCAPI is not an expensive development effort, so you can develop a custom cartridge for this. We won’t go through the details about that cartridge, perhaps on a separate blog post.

OCAPI endpoints

All the operations we want to do can be found on the Libraries resource from the Data API. To create a content asset we can use this endpoint, to assign it to a folder we can use this endpoint. One thing to keep in mind, creating a content asset is an idempotent operation. This means it creates the object if it doesn’t already exist, but if it does it ignores the existing object and writes a new one on top.

In practice, this means if someone edits these content assets (e.g. through BM, locking the resource and updating the description field), that modification will be lost. If you don’t want to lose those edits, you should consider using the endpoint to get the content asset, and use that data on your PUT request payload. In my case, these content assets are supposed to be “hidden”, so no one should need to edit them.

BM extension to create folders

Now let’s discuss the custom BM module to create folders. If business people want to create multiple filters in one go, instead of doing it through the BM UI and then going to Page Designer to assign pages to folders, they input the filter names in an input box and click a button. We can simply develop a web page that has this input box and a button (and some instructions on how to use it). This is possible by extending BM and building a custom cartridge, with this UI and the controller that executes the creation of folders. We won’t go to much into detail about this custom cartridge, I’ve added additional links at the bottom to help you building this cartridge.

Alternative solutions to SEO meta tag rules

In the case where the content object quotas are hit, we can consider building something entirely custom. What I mean is we would not use the SEO meta tag rules module from BM anymore. We would build our piece of software to handle this scenario – all page designer page types. Of course that means building software that does the same as Salesforce’s built-in module of BM, considering: Storage to store these rules, meta tag definitions, and others; an API that at least exposes a way to get meta tags for a given page, taking into account API design, SLA (important if you’ll call this in a middleware of the Page.js controller), etc.

This is a discussion you must have with your business/client, explaining the trade-offs of each scenario.

In my opinion, it’s generally often better to reuse existing functionality or an off-the-shelf solution like a plugin cartridge. Something that either is standardized and known in the community, instead of your own solution… but as always, this depends on the context we’re in. For SEO meta tag rules of SFCC in particular, we can’t extend this module. So if we really needed to support this feature and we hit the API quotas of the SFCC platform, we would consider building a cost-effective solution outside SFCC, considering the need of a custom parser for if statements, context variables… again a discussion to be made with the business and architects.

Improvements to this solution

One important note about this solution is that pages would only inherit meta tags assigned to the default folder (primary folder). From my research, a content asset can only have one default folder, and that is the folder the meta tags come from. In my use case the ideal was to setup some hierarchy, where a page could have 3 folders, and you could get all meta tags assigned to those folders. Now you kind of have this hierarchy (primary folder, then parent folders, up to root), but it’s not the exact behavior I needed.

Conclusion

In conclusion, you can develop a custom cartridge with this functionality, and support this for your business or clients. In the future, this could be supported out of the box by SFCC. The greatest challenges were: analyzing ways to extend the SEO meta tag rules module; an API to get all page designer pages and understanding the limitations of our solution. Let us know in the comments if this feature is something you’d like to have, or vote and comment on the IdeaExchange’s post. I hope this has been helpful.

Check out my other blog post on session management for SFCC.

Additional links

Here are some links to documentation and other resources, that can help you in building this feature for your business:

• IdeaExchange’s post
• How to get a list of pages of Page Designer using code?
• OCAPI Data Libraries resource
• Configuring the Business Manager Site

The post How to use SEO meta tag rules for Page Designer in SFCC appeared first on Blog IT.

Recently, I had a challenge in our production system that was a bit annoying to figure out how to solve. Who knew that code can be deployed on a production environment and not work, even though it works on all other environments…

I did some digging and asked in forums what was the difference between session management on different environments on Salesforce Commerce Cloud (SFCC). Unfortunately I didn’t find anything, only limits and good practices that didn’t help in this case.

Well that’s life right? What do you do?? You decide to be pragmatic because a feature that works and is on the hands of real people, is far better than dreams of a perfect world.

The session problem

All you know is that attributes that you are saving on the SFCC platform’s session object, are not available where you need them. For the sake of this example, let’s say we are talking about a flow between the SFCC site and an API.

The code at the moment is something like this:

// apiGateway.js script
const apiResponse = { data: "something" };
session.privacy.myCustomField = JSON.stringify(apiResponse);

The flow starts by the site calling this API, and some time later receiving a callback from the API on a specific endpoint of SomeEndpoint.js controller. Then the site makes an API call to get data (specific to a given user) for further processing. Some of it is saved in the privacy field of the session object. As stated in SFCC docs, this field is a dictionary where we can store custom properties. The next step on the flow is to redirect to an action on the Login controller, and inside that action retrieve the information that was stored.

// SomeEndpoint.js controller
res.redirect(URLUtils.https("Login-Show"));

// Login-Show action
var apiResponse = session.privacy.myCustomField ? JSON.parse(session.privacy.myCustomField) : "";
// use apiResponse for further processing

The problem happens when running the Login-Show action, session.privacy.myCustomField is equal to null so we can’t retrieve the information that was saved in the previous controller, before the redirect.

Thinking about solutions

First you try to keep using the session object provided by SFCC, but saving the data on another field called custom. The difference between custom and privacy is that data inside custom won’t be deleted when the user logs out.

Then we try to think of another approach because storing in any field of the session might not work. So we try to store this information in Custom Objects (CO). It’s important to note a very important security detail with the custom objects approach. Creating and retrieving these custom objects happen in different controller actions. So in order for the second action to know how to retrieve the correct custom object that holds the API response data, it needs the ID for the CO.

Since moving from one action to the other happens through a redirect, we can only use query parameters. On top of that, the second action is Login-Show which renders HTML to the client in the end. Which means this custom object ID is publicly available in the user’s address bar… not good! This of course means you could simply type an ID in the URL and try to find a valid custom object containing some user’s data. Of course in the Login-Show action we can retrieve the custom object and delete it afterwards. But there is still a window where this data is accessible.

In order to prevent this exploit, we add code on the Login-Show action to validate the user accessing the login page is on the same session that initiated the login flow… but wait, did I just say “same session”. If we are having problems with this session not being the same, how can we guarantee validating this sessionID will work?? We have no guarantees basically.

After a lot of thinking, experimenting and reading docs, we decide to contact Salesforce by opening a support ticket. After that we were able to schedule a meeting and showed our problem. They investigated and got back to us with feedback on what was happening to the session, during the flow described earlier.

Final solution

The final solutions is… to not change any code. The problem was the hostname that was configured in the API that called the site. We simply configured it with the correct URL, which is the same domain in which the site uses when calling this API. In order to keep the correct session in the login page after the redirect, we made these changes:

BEFORE: https://production-zone-digitmarket.demandware.net/on/demandware.store/Sites-Awesome-Site/pt_PT/SomeEndpoint-Action

AFTER: https://awesome-domain.com/on/demandware.store/Sites-Awesome-Site/pt_PT/SomeEndpoint-Action

Conclusion

Hopefully this post helped you know how session management works in Salesforce B2C Commerce Cloud. The moral of the story is: when code works everywhere except on one environment, it’s generally an environment configuration problem.

If you enjoyed this post or learned something from it, leave a comment with your thoughts.

The post Session management in Salesforce B2C Commerce Cloud appeared first on Blog IT.