Learn about Adobe Commerce SaaS offerings - Search and Catalog Service

Transcript

of the SaaS services that we have in production and kind of how it works. I think there’s, I missed the question in the chat earlier, but something about maybe going around the PHP core for these SaaS services. So effectively that’s what we have here, right? We have the traditional PHP core application that has its own kind of, now it’s covered with its own layer of GraphQL services. Next to it and separately, we now have a suite of multi-tenant SaaS services that are deployed independently of the PHP core, right? That are also invoked independently. So they have their own GraphQL API surface, which can be actually accessed using a single entry point. We call that kind of the storefront services gateway, where you can stitch together a kind of a GraphQL request that hits live search and maybe even product recommendations and catalog service kind of seamlessly behind the scenes, depending on what data you’re trying to pull back to the storefront. So what I’ll be showing you is how to basically get or establish a connection to these SaaS services and what type of configuration these need. And the good news is they’re all three are kind of built on the same common foundation. And the connection to this foundation is the same, regardless of which service you’re using. And that’s exactly what I’ll show you today. It’s set up using API keys. And those of you who use the products probably are familiar with the process, but we wanted to kind of just do a very quick review and to make sure that everyone is familiar and doesn’t have any questions. It’s slightly nuanced, but the good news is that we do have documentation. It’s called the Commerce Services Connector. This part of functionality, it’s its own module and it’s named this way because it lets you connect to these independent SaaS services, right? So by configuring it, you are establishing a connection into these, again, multi-tenant SaaS services. So the flow is generally that you generate API keys, and I’ll show you how to do that. You put in those keys into SaaS configuration in the commerce instance, and that allows you to unlock this catalog sync that’s necessary for all three of the SaaS services. And then that’s how you kind of gain access to using them effectively, right? And so what follows is our guide, and actually let me not forget to put the link to what I’m going through in the chat, just for completeness. I put that in the chat already. Oh, okay, you’re ahead of me. Knock on a hole. All right, thank you for doing that. So I wanted to, okay, I wanted to call out a couple nuances that we’ve seen as potential tripping points. So let me switch over to the screen. So the configuration for services connector, Commerce Services Connector lives under system, Commerce Services Connector under services. And the screen that you arrive at is what I’m showing now. The first thing that it asks is for the user to input some API keys. And I’ll show you how to generate those in a second. But what I wanted to highlight is that by asking for API keys, what we’re doing behind the scenes is establishing the fact that the user has entitlements to commerce as a merchant. And in order for us to validate that, the person in the organization who needs to generate the API keys needs to be the license holder, because that’s how we make the connection that, okay, this person is generating the API keys. We look up the API keys and we say, hey, do you have a commerce license associated with these keys? And if the answer is yes, then we basically give you the keys to use the SaaS services. Because the SaaS services are for Adobe commerce merchants only, and therefore we need to kind of validate that entitlement path. So here, what it says is, oh, I scrolled down too far. What it says here is that to pass entitlement validation for the services, the license holder from the merchants organizations should generate the set of API keys. And again, the account needs to be in good standing. So hopefully that makes sense. So what the license holder is going to do is log into account.magento.com. And I’ll hit that URL, it redirects to this path. And here I just created kind of a fictitious account. So I’m gonna log in with this account. And I’ll show you what the license holder will see. Actually what you will see, nothing in here will tell you that you’re a little license holder, but you will be able to tell by kind of the way that things flow downhill from here. So what you’re going to do is navigate to this API portal tab in your account. And what you’ll see here, this actually doesn’t look much like a dropdown, but it is. You can switch your environments from production to sandbox. Oh, I don’t think you see the values in the Dropbox, do you? So you can switch from production to sandbox. I’m actually gonna switch to sandbox first because these are the API’s keys that we’re gonna need first. And here’s where you are, it allows you to generate these keys. So I’m gonna say, my sandbox keys, I’m gonna hit add new, and it’s gonna give me two keys, one public, one private. And so the first opportunity you’re gonna have is to copy your private API key. And it’s not displayed for security reasons, but you can copy it to clipboard, right? You can also download a copy to your local machine. So assuming that I’ve copied it here, and I probably should download as a best practice, right? I’ve copied it to my clipboard, and now it also gives me the public key that can be displayed. So both of these are needed for configuration. So I’m gonna step back into my configuration and I’m gonna copy, or sorry, paste my values in here, right? You’re gonna see the value begins with this string and it ends with this string. And now I need my public key still, so I’m gonna grab that because that’s displayed right here. I’m gonna put it into the configuration. Once I hit save, it’s going to kind of advance me to the next screen where the pair of production keys is going to be asked for. So I generate those in just the same way that I did with my sandbox keys. So I’m switching this value here. I’m gonna say these are my prod keys. I’m gonna add new. Again, it will allow me to copy the value of the private key. I’m gonna copy it and paste it on the next screen. I can download them if I want to, and I cancel out of the download box, and this is my public production key. Again, the configuration asks for both pairs of values. So assuming I put in my sandbox keys here, I saved. I’m gonna assume that I populated my production keys here. I’m gonna save. Once I’ve entered both pairs of keys, it should allow me to advance in here into my actual SAS identifier. Here’s where you select what we call a project and a data space. A data space is just some cloud storage where all of your data is going to live, all of the data that is required for our cloud services. So for example, the catalog data that you send from commerce to be used for search, a catalog data that you send from commerce to be used for product recommendations, it’s going to live in a specific data space. And those data spaces are going to belong to one project. So if you are entitled, and as a merchant, you will get three data spaces, so one to be used for production and two for testing. If you are signing up as a partner, we actually give you more data spaces. I think you get five. So you get one to be used and it’s your production level data space and four for the purposes of testing. Again, the entire set of those data spaces are going to belong to one project. So there’s a default name, and I forget what, I think it just says my project or something by default, but you can rename it. Here, this is kind of my internal teams project, right? I just see, most of the time, you’re just going to have one. Unless a merchant has multiple commerce licenses, sometimes they will get entitled to multiple SaaS projects. But anyway, these data spaces live under a project. So if you are entitled and you pass the validation check, here in the data space, you will have three options, one for, again, production and two for testing. And actually, I’ll show you down here. If you are an Adobe commerce merchant, you get one production data space to testing. Or if you did not pass the validation check, which kind of implies you’re using load-based source, you will see only one production data space and no testing instances. That’ll be a clue that the entitlements validation did not pass. Okay? And again, if you’re a partner, you should also see multiple. I think it’s one production for testing. And that’s really it. So once you select the data space to be used with this particular commerce instance that I’m on, that is the place where your data is going to get exported to and that’s where it will live. And again, like a strong word of caution, right? You shouldn’t really mix and match. You shouldn’t configure multiple commerce instances to send data to the same SaaS data space, because then you get pollution, you get overwriting your data, you get mixes of URLs and all kinds of mess. And obviously it matters the most for production. So please reserve your production data space for use with only just your production environment. Otherwise you risk, again, polluting data and it’s always bad in production, right? A little bit more context here. If you do end up in a situation where you’ve polluted the data space, for now you can file a support ticket to just wipe a data space off of Catalan data. And we can do that pretty quickly. We’re also working on some tooling. Experience has taught us that it’s probably best to just make these things a bit self-serve. So we are working on tooling that will allow the user themselves to perform that operation. For now, we’re still in a state where it requires a support ticket, but in the future, we are looking to introduce functionality that will allow you to do it, again, from either from here or from CLI, we will let you know in documentation, right? But that’s an improvement you can look forward to. So once you have, again, once you’ve set your data space in here, you can now access features like in my sandbox here, I have product recommendations, I have live search. And if you’ve configured everything correctly, you will arrive at a dashboard that you may or may not have recommendation units here already. If you’re setting it for the first time, likely it’ll just be an empty grid, right? With an option to create your first recommendation unit. But if it detects that you haven’t completed the setup process, it will direct you back to the Commerce Services Connector setup to where you can set up your keys. And so once you’ve hooked everything up, again, you can use these features, you will only have to do it once, regardless of what services you use. So whether you’re setting up your first time for product breaks, then when you install live search, everything’s already configured, you don’t need to do anything extra for any subsequent services. That is all of the content that I have. I haven’t been keeping an eye on chat, but I will go look in there and kind of free up the stage for somebody else. Brad. Thank you, Misha. I think that’s a good level set for just some of the basic configuration that’s needed for all of our SaaS services. And cues up Fahad nicely to talk about catalog service, which you mentioned is one of the newer capabilities, product recs being first, live search second, catalog service now being this read only access to our catalog that makes site experiences faster, more highly performant. So I’m gonna turn it over to Fahad to walk through some of those use cases for catalog service. The floor is all yours. Absolutely. Thank you so much. And yes, it segues nicely into my, I’m gonna go ahead and start sharing. Please tell me that you can see my screen fine, even in presentation mode. Correct. All right, awesome. So as Misha nicely went on with the onboarding of it, one of the things is the platform is still the same and catalog service is a service that we released just earlier this year. And, sorry about that. So yeah, so this, we released it earlier this year. And one of the things that happened here was you can pick and choose, which means that it’s also comes with a federated gateway that gives you a catalog service, or you can go with live search or prereqs at the same time. The key reason for catalog service is of course, it allows headless storefronts, but it’s performance and scalability. So basically we’re looking at performance somewhere at 99 percentile within 250 milliseconds. Another thing about this is that when you think about it, we have looked at it, not simply from the perspective of providing catalog service API that just performs CRUD, like giving you a catalog product or, especially with massive catalogs that can become a problem. So one of the demos I’m going to do is what we call a fitment use case that showcases a refine API. But before I get into that, I’ll just quickly go ahead and revisit the architecture, the high level architecture of our SaaS services. On the left hand side, you can see our Adobe commerce instance. And on the right hand side, there are services that are SaaS platform. So going from bottom to top, obviously the first thing we need is catalog sync, which is what you enable when you go through that onboarding process. And if you have the entitlements, it will automatically kick off the SaaS data exporters, and it will go into our catalog indexing. One of the things that we have kept in mind is also the performance of ingestion. So a lot of times, if you see your price indexers are the biggest bottleneck. What we have done is we have moved the price indexers into SaaS as well. So the SaaS service layer does a lot of heavy lifting there that relieves a lot of pressure from your Adobe commerce instances, better maintainability, lower total cost of ownership, along with the scalability and performance. Then, by the way, all our services are API first, right? So we have admin SaaS services available as well as API first. Obviously it comes out of the box with the admin UIs, you have your services connector that we just went through, you have your live search configuration, your P-REX and catalog service configuration and payments amongst other things. And then comes the storefront APIs. These are the APIs that your shoppers, the anonymous shoppers are gonna leverage and make the site really, really snappy. With that, I’m gonna go ahead and showcase some of the things here. The thing that I wanna focus on is the second API there, which is GraphQL Refined Product. What does Refined Product mean is that if you have multiple options in your product and things change depending on what options get selected. So one of two things happen. Either you select one option, a value for one option, and then there are certain values that are changed for other options because it needs to only filter out the applicable options. And when you select all the options, your prices may change, other things may change, right? So here we’re not technically looking at just give me entirety of your product catalog, but you’re actually saying, here’s the product, here’s the selections, now give me the options, the applicable options. And as you can see, it’s still within our 250 milliseconds, and it really allows us to really improve the experience. And now I’m gonna go ahead and show, Ed, can you just tell me if you’re still seeing my screen because I’m changing the screen? I am, yep. Perfect. So if you look here, here’s a fictitious automotive, right? So actually one of the ways this is, there are a couple of ways where this problem presents itself. In automotive industry, there’s something called YMM configurator. Some of you may be familiar with your make model, and it’s basically the same thing, but if you have like a big automotive company and you are selling auto parts for half a century of like cars that you have on your catalog, then that becomes a really huge problem, right? And so that needs extra maintenance, people maintain indexes and stuff. So you can think about this like that, although it’s all fictitious as you can see. If I choose a different color, notice my price changes. This is a demo site, so don’t worry about the numbers. The numbers don’t make any sense anyway. I’ll take an option here, and you’ll notice that the price should change again, and so you can see the price changing. Before I move on, I wanna go ahead to the Chrome tab here real quick, and show you what’s happening and what calls are being made. So what I’m trying to show you here is anytime I change an option, you’ll see that it makes a trip to our SaaS service. So here you go, you can go here, and you can see that the trip is being made to our catalog service pre-prod, and it actually, the trip that it’s making or the call it’s doing is the refine API. It’s within milliseconds, so you don’t have to, if you’re using our SaaS services, you don’t have to do the heavy lifting of maintaining all these indexes and whatnot. Quickly, and this will wrap up my demo, is what’s happening behind the scenes. So here’s, I have the GraphQL console, and you can see, hopefully, that I have two option IDs already there, the color, and I believe the other one is the engine size or something. So in options, you won’t see those two options. You’ll see the option that is not there. So you’ll see fuel type and transmission. Let’s go ahead and select transmission. Let’s say the user actually creates a, or selects this transmission, automatic ID. I’m gonna send it again. The production is much faster. So then you go in, and if I look at options again, notice that now it doesn’t give me other options anymore. It just gives me the one that I haven’t selected fuel type, and the one that is applicable to the options that you sent in. And obviously, your price range also changes. All of this is happening just via API calls. And so we hope that this allows our customers, especially the upmarket customers that have massive catalog without having to maintain heavy indexes on their side. That concludes my part of the presentation.