Commerce Integration Framework (CIF REST) on Cloud for Magento
This project is feature complete and for demo purposes only.
For production projects, use the new way of integrating Magento with AEM: AEM Commerce connector for Magento and GraphQL.
The CIF REST services architecture is based on Apache OpenWhisk & Adobe I/O Runtime. The main building blocks of the new commerce services are serverless functions (OpenWhisk actions). These actions run on Adobe I/O Runtime inside an isolated container, stateless and serverless interacting with the commerce backend system or other endpoints via their APIs.
This project contains the OpenWhisk actions implementation for Magento.
Magento GraphQL and aggregated cart extension
This project is organized around commerce microservices. Each microservice domain lives in a separate folder and is developed and released independently. All code is organized in the
src ├── carts ├── categories ├── common ├── customer ├── orders └── products
common folder has a special role, it contains code which is re-used across multiple microservices.
The project also has dependencies/relationships to the following sub projects:
|commerce-cif-common||Common code for CIF REST implementations: common actions, validators, exceptions.|
To get started with CIF REST, first make sure you have the following tools installed:
- Node 7.x or 8.x
- NPM 4.x or 5.x
- OpenWhisk CLI
OpenWhisk CLI must be available in your systems PATH and set up correctly to either use a local OpenWhisk installation or an Adobe I/O account. Try
wsk --help to make sure it is working.
Build & Deployment
To install all the npm dependencies and bootstrap lerna, simply run:
$ npm install
The "real-world deployment"
The real-world deployment scenario consists of a 2-namespaces (provider and consumer) scenario.
(Note that switching between users/namespaces just means updating your
~/.wskprops with the credentials of the expected user/namespace)
Provider shared packages
The packages and actions developed in this repository are meant to be deployed as OpenWhisk
shared packages: we call this part of the deployment the
provider part. This deployment should be done by a user/namespace meant to provide shared packages to other consumer/customer users. With the provider
~/.wskprops file set and in the top/root directory of this project, simply call
$ lerna run deploy-package
to create all the shared packages and deploy all the actions in the
provider namespace. By default, the consumer/customer deployment part (see next section) expects that the provider namespace is called
cif-core, but this is not mandatory.
lerna run deploy-package will simply call
npm run deploy-package in all the subfolders under
For each microservice domain like
products, running the
deploy-package script will create 2 shared packages in the provider namespace like for example:
/email@example.com(at the time of writing this doc)
The 2nd package with the
latest version is meant to always contain the latest version of the microservice. This is also used by the consumer/customer deployment. If everything worked well, calling
wsk -i package list should show all the shared packages that have been deployed.
To remove all the provider packages call
$ lerna run remove-package
To deploy/remove/redeploy the actions of a microservice domain, see the corresponding README for each microservice.
The folder customer-deployment contains a sample deployment project that demonstrates how a consumer/customer would use some shared packages deployed by a provider. See the README in this folder for instructions. Remember that you will have to switch to a consumer/customer
~/.wskprops file when doing the consumer/customer deployment.
Build & Deployment notes
The repository contains multiple node packages with local cross-dependencies. To automatically handle these dependencies and build all packages, we use the lerna tool.
lerna clean removes the
node_modules directories of all the node packages under
src/. Only call
lerna bootstrap to reinstall all the
node_modules dependencies for all the packages (this is typically done once to initialize all the packages or to add new cross-local dependencies). It is usually better to always call
lerna clean before calling
lerna bootstrap as lerna seems to have some issues with circular dependencies.
If you change the code of an existing action, you don't have to use
lerna for anything, just redeploy your action/function. If you add a new Node.js package with new actions under
src/, just call
lerna clean; lerna bootstrap from the root of the repository. If you add some (remote) Node.js dependencies to a package, just use
npm to install the new dependencies for that package. If you add some local dependency from one package to another local package, call
lerna clean; lerna bootstrap from the root of the repository.
The OpenWhisk actions can be deployed using serverless framework.
Actions and sequences are declared in the
serverless.yml file of each business domain class located under
To deploy all actions in one of the
./src folder, you can call
npm run deploy, and to remove all actions just use
npm run remove.
For reference, during the deployment, actions are zipped and stored in the
It is also possible to use
serverless directly to deploy a single action. First navigate to the action folder (i.e
./src/carts) and execute
$ serverless deploy function -f NAME (with
NAME referring to the name of a function declared in
The execution of
npm install will automatically trigger a script, that downloads released module dependencies declared in the
For testing, each package is configured to perform a static code analysis using ESLint as well as executing Mocha unit tests. For unit tests, chai.js is used for assertions and sinon.js can be used for mocking. We use istanbul.js to collect testing code coverage.
To run linting, tests and coverage analysis for all modules, run in the root package:
$ npm test
The same command is also available for each individual package. Running individual ITs is also possible:
$ NODE_TLS_REJECT_UNAUTHORIZED=0 OW_ENDPOINT='https://hostname/api/v1/web/cif-customer' npm run test-it
System environment variables, like OW_ENDPOINT can be adapted to use a custom OpenWhisk environment or namespace.
OpenWhisk activation log provide logging information for your actions. Use:
$ wsk activation list
to get the last action actions and
$ wsk activation get <id>
to get the log details for a particular activation.
If you run OpenWhisk locally it is possible to get detailed logs by using the
wskadmin tool available directly on the openwhisk server.
To get some detailed logging info, just use
wskadmin syslog get -g activation-id with the
activation-id of the action you want to debug. Then identify the tag
tid_XXX in the output, and use
wskadmin syslog get -t XXX to get some detailed information about that so-called transaction.
Contributions are welcomed! Read the Contributing Guide for more information.
This project is licensed under the Apache V2 License. See LICENSE for more information.