The Past, Present, and Future use of SFCC’s OCAPI
Hello there. First of all, what is OCAPI?
It’s SFCC’s API, Open Commerce API (OCAPI), that allows any application to securely access your organization’s SFCC resources for products, orders, baskets, etc… to interpret, manipulate, or present that data to another application/system or user, as well as creating, reading, updating, or deleting data in SFCC. As stated, this can be done outside of SFCC, to present data to other systems like SAP, or to make updates directly to your SFCC store through OCAPI, effecting real orders, customers, and more.
Excerpt from the SFCC Documentation:
“OCAPI is divided into different APIs: the Shop API allows a client to interact with the system as a shop customer or as an agent shopping on behalf of a customer, the Data API gives create/read/update/delete access to system resources, and the Meta API is used to retrieve a formal description of the Open Commerce API, including custom attributes.”
Why use OCAPI? I think the most important answer is freedom. Specifically, development freedom. With OCAPI, we have the freedom to go outside of the SFCC strict framework of code development, and use any platform or language we like to write applications, job processes, or even full storefronts with something like a PWA (Progressive Web Application) or a headless storefront to do much, much more than the SFCC platform can do, or was designed to do. As we move into 2023, it seems like development, for larger applications especially, is moving away from the giant, slow, monolithic Server Side Rendering approach, to a more iterative, flexible, faster, scalable, and easily maintained approach using CSR (Client Side Rendering) or an SSR/CSR hybrid, and various API’s to do anything and everything. There’s almost unlimited use cases for OCAPI, and with the freedom to use any platform (AWS, Google Cloud), and write the code in any language or framework (Node, React), any business need could be met with this tool.
How to use OCAPI? OCAPI can be used simply with an SFCC client id, added to the application, and in the SFCC BM (Business Manager) Open Commerce API Settings. The client id must have the required permissions to use OCAPI and its resources, and the resources used in the application must be specifically stated in BM. In some cases, the client password is also needed to access the resources.
The Past
In this scenario we’ll see how things were done in the past with SFCC in certain use cases before OCAPI could be implemented. We used to use an SFCC Job to process all orders coming from SFCC, that needed to go to SAP to be completed. In this specific case, we used an SFCC job process to export the orders from SFCC as an XML file, transform and/or update the orders with multiple job functions, and upload the orders to an SFTP where they would be picked up by another process by SAP. This was a multi-step job that had to be ran multiple times a day, maintained with code updates, and monitored while the SFTP had to be checked regularly to make sure all processes were working correctly. This job also had to correlate with other systems like SAP to pick up these XML files from the SFTP at certain times throughout the day. This was a very complicated, multi-step process, that required much effort to maintain. This required working with outdated XML files, and writing many different functions to work with XML files and XML objects in code, that were inherently difficult to work with. It also created a reliance on these XML files, and did not allow any updates to newer technologies in SFCC or in SAP. The steps for this process were:
export orders > transform orders (multiple functions) > transfer orders to SFTP > pick up orders by SAP > SAP order process functions.
The Present
Now, we use a middleware application to do all of this work in two simple steps. This application uses OCAPI to perform all of the SFCC functions needed. This application runs as an AWS Lamda function every hour and will automatically pick up any new SFCC orders, push them to a queue in AWS, process the orders, and send them directly to SAP. Using OCAPI to get new SFCC orders, and update orders with data from SAP (shipping, payment related), allows a very quick process to be ran that can handle all of these requirements. The process will start a function using OCAPI to get all new orders from SFCC, and after a series of checks, determine which orders to add to the queue. Those are added, and then processed by another function. The process function will take those orders, update them if needed, transform the data so that the SAP API can accept them, and then send them directly to SAP (via API) as completed orders. This all happens in only a few minutes. The whole process is now: get orders and add to queue > process/update orders > send to SAP as complete. This is all done in an easily managed application on AWS, with it’s own logs that can be customized and monitored in AWS and other log centers, and any errors can be sent to Slack to be investigated in real time. The code can also be easily updated and deployed in minutes. OCAPI allows the development of this application to be done completely outside of SFCC, in any language, on any platform, and connect to SFCC for all the important data (orders) needed for this process.
The Future
This is just the beginning. OCAPI has many, many uses in the world of SFCC, and we are only at the tip of the iceberg right now. The API can be used on the frontend to create “headless” pages of the storefront with client-side routing and rendering for fast, dynamic, behavior across the Homepage, Marketing/Custom Pages, PLPs, PDPs, the Cart, and more. More applications can be used on the backend for business critical functions around orders, payment, customers, etc. Integrations with other applications (Fender Play) or 3rd Party/vendor applications/APIs (Topps) can be done to support any features in development surrounding SFCC. This can also greatly help decouple SFCC from the strict format in place, so that it can be used inside other applications like Fender Play, to create or update customer orders purchased outside of SFCC, or on its own as a standalone mobile application/PWA of the storefront. With this, SFCC could be used almost anywhere, and in any use case. SFCC has already created this PWA Kit: https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/getting-started.html
which is a framework for creating storefronts with React, and heavily uses OCAPI and SCAPI (Salesforce Commerce API). The future looks very bright for storefronts and applications using SFCC’s OCAPI.
