ÃÛ¶¹ÊÓƵ

Transcript

Hello and welcome again to that lesson of the course covered integration startup kit. In that third lesson we were talking about the LASMA integration and how is structure the invoked action that you will need to extend to connect with the startup party system. On the left side you can see the standard design of the startup kit. Here highlighted in green you can see the invoked actions, basically the actions where the solution partners are building the LASMA integration. Here you can see how looks the invoked action when a customer is being created in commerce. As you can see here there are five completely independent blocks for each one of the sensitivity hooks that we mentioned before. Each one of those blocks have their own JavaScript file to ensure you can keep separated your business logic meanwhile you are keeping the design of the startup kit as it was before to ensure in the future you are able to upgrade the framework. This pattern is exactly the same for both the directions. So that extensibility hooks you will be able to see them. Whatever you are looking for invoked actions from commerce or from third party systems. Now let’s go one by one and check what are the typical use cases that could be applicable for each one of those hooks. The first hook that we are finding in a invoked action is on the guard of the validation hook. Inside the validation hook we can be seen two pretty typical use cases. The first one is on regards on the incoming data. Many systems allow you to configure which are the fields that you want to send to an appeal application. So it’s a pretty good common practice to ensure that you validate the event, patterns data, and ensure that this validate against the schema to avoid any error in the configuration and that specific data is not coming that is expected due to the transformation and integration with the third party system. The second typical use case is on regards of being able to skip or discard specific events depends on the values that are part of that specific event. A pretty typical example could be if you want to send to an ERP system if a specific download of all products because they are not interested on that type of product. So you can be adding on the validation schema the skipping of the rest of the processing of the event depends on a specific value on one of the fields. The next hook that we find in any invoked action is a transform hook. The transform hook basically is the responsible of transforming the data object from the origin system to the data object to the destination system. So basically here on that example we can see how we are transforming the product entity from the commerce side to the third party system. In that example we are basically doing the data object mapping between ÃÛ¶¹ÊÓƵ Commerce and Microsoft F&O. So aside of the typical field name mapping or specific map exercise between some of the fields we can be also adding constants that are required in the destination API and should be hardcoded for the specific integration or business case required by the merger. The preprocess hook is helping you to being able to do any required calculation before the send data of any relevant information that is required for the destination system. Here in that example we could be seeing as part of the event we are getting the group ID of the customer group associated with the customer. However, the destination system is expecting the code to be used on the send data. So in the preprocess we are basically calling back the system and doing the calculation about what is the code and we are sending that path of that transformer. That transformer came back and could be useful for when you are sending the data you are not only having the information about the incoming data of the event you are also having the calculation being made during the preprocess for you are using that during that send data hook. The next hook that we are finding is the send hook. Basically the send hook is the hook responsible of doing the send of the data to the destination system. So basically in the same data we will be finding things like getting the token and connecting with the third-party system. We recommend as a best practice to try to unload most of that API request inside a specific library on the system that you are connecting. So for example in our case as we are connecting with T65 or most known like Microsoft F&O we are involving all that requests on the specific functions to ensure we are obfuscating things like getting a token and connecting with the final API destination. So basically that send hook is the one that is doing the real connection and is triggering all the required APIs to ensure proper synchronization between the two systems. Last but not least we have the postprocess hook. Postprocess hook allows you to do any kind of post-processing activity getting the result not of the same data but also all the original incoming data. So in the example that we are showing here we would like to add a comment to the original order after this order has been synchronized with the external system. So here we will be adding back a comment in commerce telling that the synchronization was made successfully and what was the id of the order in the destination system. Another typical use case could be that you want to store in a specific attribute in atomic commerce the external id of the destination system or that you want to notify to a third party system also being in charge of one specific entity about the specific synchronization has been successfully being completed. We hope that you enjoyed that lesson 3 and as always remember that you have the cold samples available or the public documentation and also some slack channels if you have any questions. Thank you.