This connector package is divided into several maven modules. Which are explained here.

Not all modules are included by a default maven-built. Some modules are intended for demonstration purpose, only and ommited in a normal built.

The Maven pom.xml at the docroot of this project is the reactor for all modules. That means, it includes <module> definitions for all the sub-modules. It does not contain any information besides that.

Build-only

$ cd commerce-salesforce
$ mvn clean install

If you want to directly install the package to your local development environment, you can call the build with the according profile:

Build-and-install

$ cd commerce-salesforce
$ mvn clean install -P autoInstallPackage

The parent contains the settings and configurations, that are commonly used among the sub-modules - like variable definitions and version numbers for plugins and dependencies.

Bundles is not a module but a folder, that contains the actual sub-modules that are build as OSGi bundles.

The sub-modules can be build as part of the reactor project. In this case, the bundles will be included in the folder /apps/commerce/demandware/install of the AEM main "Content" package

Each sub-module also can be build individually. This is especially useful, if you are working on the source of an individual bundle, that you quickly want to deploy to your local AEM instance.

In this case, you don't want to build the whole project and wrap te artifacts in an AEM package but you build the bare bundle and deploy it directly to the Felix-console.

Direct deployment is triggered by a profile. For example, to build the core bundle you would call

Build:

$ cd commerce-salesforce/core

$ mvn clean install -P autoInstallBundle

This bundle includes all helper services that are required for rendering the joint AEM/SFCC preview in AEM.

Note: This project does not use Sling models, but JavaScript-based models. Thus, the logic for the models is not in the core but in the content module.

...TBD...

This bundle contains the code that is required for importing XML-based product catalogs from SFCC.

Look here for code that relates to the replication of Content Assets, Slot Configs, Assets, etc. from AEM to SFCC.

This bundle contains all dependencies to external libraries that are not found in a typical AEM installation. It does not contain any code, but the pom.xml references to 3rd-party libraries in a Maven-repository which is downloaded and wrapped whern this project is built. You would rarely build this project individually or more than once.

This bundle contains a helper servlet, that can be used to prepare a remote SFCC sandbox with SiteGenesis related demo content. This bundle only contains the bare servlet. There is a "companion" resource in the content package, at apps/commerce/demandware/components/init that actually is used to store the configuration and trigger the init servlet. It is not used in a customized or production environment.

This package contains all resources, components, templates, dialogs, etc. that are required for a bare minimum installation of the Connector.

Note: As the project now is open-source, The package is completely "rooted" in /apps, where the 1.x version had parts in "/libs" that you could overlay. Even though the resources are in "/apps" you must not overwrite resources in this packages with your own implementation. You should always be able to checkout the latest open-source version of the connector and install it in your system. If you use the same paths as this version does, an update would overwrite your customizations. You should reference your own implementations explicitly in your content (e.g. by referenceing resourceType=/apps/<<myapp>>/commerce/...) or add your path to the Sling resorce resolver's script resolution search path.

This package also contains a default replication-agent that is pre-configured to be used with SFCC. This agent is disabled by default and there is no User ID configured.

Most likely you want to use this as to copy&paste your own replication-agent. (see Users and Permissions why it is important to define your own replication agent).

Moreover, the package comtains the definition of a system-user, that is used to run the Connector's services.

Note: This package does not contain any "real content" that is visible to authors. A future version might perhaps call this package "resources" to help distinguishing the different types of content.

This module - and the resulting package contains some sample OSGi configurations, that are used in both the content-sample and content-multi-sample package (see below).

Where possible, we provide resonable defaults for the configuration. However, you would always have to copy this package to provide your own values for credentials for WebDAV and OCAPI.

To prevent you from inadvertently overwrite your own configurations when building the reactor project, the base-config is only installed on your local machine when you call the reactor with:

$ cd commerce-salesforce

$ mvn clean install -P installBaseConfig

This package installs the following sample resource:

• Content for the SiteGenesis demo website
• Content - Mappings (see Content Mapping)
• OSGi configurations (see Configuration)
• a Replication Agent
• the according system user for the replication agent (Note, the system user for the services is in the base-config package)
• Basic ACLs for the replication agent's user in the demo content (see Users and Permissions)

This package is used as a demonstration on how to set up the connector to connect one AEM instance with one SFCC instance. You might want to study the contents and install the package on your local system. This package however, would never be used in a production environment.

The package is only installed, if you call the build with the explicit profiles:

$ cd commerce-salesforce

$ mvn clean install -P installBaseConfig,installSampleContent

Don't forget to configure your WebDAV- and OCAPI credentials in the according service configuration files.

This package basically contains the same artifacts as the previous one.

Only now, it demonstrates a scenario, where you connect one AEM instance to two different SFCC instances:

It contains two separate content trees, that are associated with two separate replication agents (implicitly by setting according read-rights).

The necessary OSGi services, Demandware Client and the Acces Token Provider also are configured twice with different instanceIDs to factor in the two separate SFCC instances.

Don't forget to configure your WebDAV- and OCAPI credentials for both instances in the according service configuration files.

You must explicitly include the package in your reactor build with:

$ cd commerce-salesforce

$ mvn clean install -P installBaseConfig,installMultiSampleContent

The same applies, when you directly build the package from the modules directory:

$ cd commerce-salesforce/base-config

$ mvn clean install -P installBaseConfig

$ cd ../content-multi-sample

$ mvn clean install -P installMultiSampleContent

The sample content packages use the "merge-mode" to install. This is done as a precaution to not inadvertently overwrite content that has been edited in the UI (and would not be backed up).

However, when experimenting with the content, we found it useful to have an automated job, that could clean-up all sample content, so we could start from scratch with a new, pristine repository.

Warning: Make sure you understand the package's scope before you use it.

This module deploys an "empty" package defined for the regions that are used by the sample content. As the package is empty, it deletes all content from the repository that fall within it's defined scope.

The module is "protected" by requiring a special profile:

$ cd commerce-salesforce/clean-up-sample-content

$ mvn clean instal -P cleanUpSampleContent