Back office Integrations using the Adobe Starter Kit

Transcript

Welcome to that first training about commerce integration and startup case. On that video today, we’ll be talking about best practices for cloning to life. So basically, we’ll be touch-facing in all the most important tricks and best practices for not only being managed to onboard, continue, but also how to develop and deploy your applications. The following section will be around onboarding. So we will be focusing on the steps required from the cloning and installation to being able to validate that your application is being deployed successfully. You are seeing here in developer.atomic console just a blank project that we just created. In the following video, we’ll be showcasing the case that we are trying to build an integration with a CRM system where Adobe Commerce will be the system of truth for product and order gathering versus in customer, we could be having been creating and being managed in both of the systems. So there will be a bidirectional communication between the Adobe Commerce and that specific CRM. If you don’t know how to create that project in the RIMMY file of the startup kit, you have the step-by-steps. Specifically for that video, because we want to focus on development, onboarding, and deployment, we’ll be jumping to the step where we start to talk about the boarding, but remember that in the RIMMY file, you have all the steps required to all the parentheses. Okay, so now that we already saw the RIMMY, let’s go to the idea to show how we already executed all the required steps for configuring a project. So we can see here how we are we have the M file already being filled with all the credentials required for the rest of the boarding. And also, if we go to the AppConfig channel, we basically command some of the actions to basically do not do a deployment of all of them and only the requirement for the use case that we were explaining before. This is why we basically commented everything that is stock related and also information coming back from the back office at all the level and a product level because we are only having three entities on that case. So now we will go to do the IO AppDeploy. This basically will spin up all the required runtime actions for all applications ready to be used. So after that command will be ending, we’ll be coming back to developer.adobe.com console and we will be seeing how our stage environment now is having all the runtime actions available to start to configure providers and the required registration between the events and that runtime actions. Once our application is deployed, we are ready to onboard. But before, let’s take a look to the configuration files used to tailor the onboarding process. These files are located under the scripts onboarding and scripts commerce event subscribe folder. The fifth file we will look at is the provider.json file. It is used to declare the event providers that need to be created to support our application business logic. In this case, a commerce and a back office provider. If extra providers need to be created, for example, a provider to receive events from a pin system, they can be specified in this file. Next, we’ll look at the starterkitregistration.json file. It is used to specify how our application is designed from an event perspective by specifying what are the sources of events for each entity our integration is interested in. As described before, our sample application is listening to product and other events triggered by commerce and for customer, it is interested in events from both systems in order to create a bidirectional synchronization. We can’t remove stock from this file because our application does not handle this set. The events.json file is used to specify the events our application will accept from each source for each entity. For our example application, we have to leave commerce events for product, commerce and back office events for customer, and commerce events for order, and remove all stock related events. The future versions of our application will support, for example, order status changes from the CRBEM. We can get back to this file, add back the order back office event, and run the onboarding script. Now that we are done with the configuration, we can run the onboard script which will create and configure the VEM providers, create the connection between commerce and app builder, and subscribe runtime actions to the appropriate events. Once the onboarding script completes, we can navigate to the developer console to confirm that the expected event subscriptions have been created. In our case, we should be seeing back office and commerce synchronizations for customer, and commerce synchronizations for order and products. We can also validate that each subscription is listening to the events we configured in the events.json file. By clicking on the debug tracing tab, we’ll also be able to confirm that the runtime action responded successfully to the challenge prof request. Let’s also validate that the onboarding script configured the Adobe IOO events module in our common system. In the admin UI, we should see the Adobe Commerce instance ID, Adobe VEM provider ID, and merchant ID fields populated with badges. The commerce events subscribed.json file declares the events we want to be propagated from commerce to app builder. To adapt it to our use case, from the populated values in the file, we will leave only the events our integration is interested in, which are those related to product, customer, and all. And remove the ones related to stock that our application does not use. The events specified in this file can be automatically configured in commerce by running the commerce events subscribed script. Once the script completes, we can update a product in the commerce admin UI to validate that the events have been configured properly. When saving, a product save commit after event will be triggered. The event will hit the commerce product synchronization event subscription and activate the corresponding runtime action in AppVid. The commerce events subscribed script will only work if the Adobe IOO event module version in your commerce instance is 1.6.0 or great. Otherwise, you’ll need to manually configure the events in commerce as detailed in the starter kit rhythmify. The following section will be about deployment. In that section, we will be talking about best practice about how to make your life easier from a coding perspective and which are the tools and scripts that you can take advantage for to make your development life cycle much more productive. The fastest practice that will help you to speed up the development life cycle is to deploy individual runtime actions. Because when doing so, the deployment is considerably quicker than deploying the whole project. To finish this lesson, we will show how to add a new field to an existing event. We will start by navigating to the commerce events subscribed.json file. Notating the event we want to modify and adding to it the extra fee. In our example, we are going to add the price to the product’s a.commit after them. Once we are done modifying this file, all that needs to be done for the changes to take effect is to run again the commerce events subscribed script. After the script completes, we can validate that the new field has been added to the event by updating a product in the commerce admin UI. We can then navigate to the developer console and compare an event payload generated before the change which did not contain the price field with the new event payload received which enclose the price as expected. Thank you for your time today. Have a happy coding and please see all the videos available for all current course about Covert Integration Starter Kit.