Pages - Menu

Demandware - How to replicate from PIG to SIG

Scope

Typical scenario where we want to bring down a staging instance from Primary Instance Group (PIG) to one of our sandbox so we have up-to-date contents in our Secondary Instance Group (SIG). By default, Demandware does not have this functionalities and cannot be done out of the box.

Solution

One easy way to achieve this is by doing this.

  1. Go to Business Manager in PIG
  2. Administration >  Site Development >  Site Import & Export
  3. Export site and Save in Global Export Directory
  4. Optionally run dbinit in SIG via Control Center
  5. Go to Business Manager in SIG
  6. Administration >  Site Development >  Site Import & Export
  7. In the Import panel, the site backup will be available as global location.


Bitbucket Continuous Integration with Bitbucket Pipelines

Scope

We use Bitbucket as our SCM and other few Atlassian products in our development team. Happy to say that I am pleased with the tools that it made our daily works very productive and hassle free. 

Recently, I am looking into a CICD solution for our deployment process. I have already previously Setting Up Jenkins for GitHubSetting Up Octopus Deploy for Jenkins with nopCommerce Projects or Setup Continuous Integration with Visual Studio Online. I like the design of Octopus Deploy, but given we are now happily living with our Atlassian suite, I want to see what the Bitbucket Pipelines (formerly Bamboo) can offer me. 

I just signed up for the Bitbucket Pipelines Beta and already received the beta invitation within about 6 hours :)




Goal

  • Setup and integrate Bamboo with Bitbucket.
  • Explore possibility to automatically run the Demandware Grunt Build Suite when we commit to master.

Setup

I clicked the link to install the Bitbucket Pipelines add-on.
Went through a simple setup procedure and enabled it in my repository.


It adds a Pipelines link in my repository.

Going through the wiki to configure the bitbucket-pipelines yml.

It is essential to understand the Docker Image used by Bitbucket pipelines. The default image uses ubuntu and is good enough in our scenario.

In the setting tab, we are able to setup environment variables for username and password.


We created a bitbucket-pipelines.yml script in the root folder.



Check-ins to the master will trigger the Bamboo to run the build job and script.



Thoughts

I have not had much chance to explore further, but it looks quite promising and does what I wanted. I like the fact that it is tightly integrated with our bitbucket so I do not need to login to another service, the setup was simple and straightforward.

"Build servers build" - Bitbucket is a CI server and not a CICD server. We will leverage Bitbucket Pipelines for our continuous integration and our Demandware Business Manager Code Replication for deployment purpose. I am pleased with the Bamboo Pipelines, this should work well and fits our CICD strategy.



Demandware - Implementing 3rd party FTP Service for XML Drop

Scope

I developed a few Demandware cartridges that export xml via ftp for 3rd party integration. A few things that I have done such as:-


  • Piggy back a ftp drop task to the current job schedule that imports xml from a difference integration point
  • Using standard Demandware pipelet to generate a xml feed for ftp drop
  • Create a custom script node to generate a xml feed for ftp drop
It wasn't too difficult as a job, but I found a few hidden gotchas that I believe are noteworthy.


We are dealing with the latest Demandware version 16.7.

Technical

FTP Constraints

  • Ftp connection is established using passive transfer mode (PASV) only.
  • Demandware only support ftp and sftp for backend integration, no ftps.
  • Use FTPClient for ftp; and SFTPClient for sftp.

ArrayList

In our code, we use dw.util.ArrayList to filter out products for export. We ran into an error where the ArrayList cannot be bigger than 20,000 in size.

Front End Debugging

I was testing out a pipeline-startnode by direct url from a broswer, it did not turn out well because some of the pipelets can only be executed from the backend. The error message looks like this.

com.demandware.core.quota.QuotaExceededException:
Limit for quota 'api.pipelet.ImportExport' exceeded. Limit is 0, actual is 1.

Job Schedule

We tried to schedule a job for our cartridge and learnt in a hard way that JS Controller is not supported for Business Manager Job Schedule. Only pipeplines can be used.

Traversing XML

If you happened in need of traversaing the xml, Demandware uses ECMA scripts for XML. Here is a quick start guide.

Firewall

Besides the firewall rules that I needed to manage with our external vendor, we also need to request outbound firewall rule from Demandware.

As they pointed out in their doc, "Before you can make an outbound FTP connection, the FTP server IP address must be enabled for outbound traffic at the Demandware firewall for your POD. Please file a support request to request a new firewall rule".

From Demandware, there are steps to request a Firewall rule to allow outgoing connections to 3rd party services.

Demandware - Monogram by using Product Options

Scenario

Our business wants to start selling personalized product by monogramming. In this particular promotion, customer gets a free monogrammed luggage tag when they buy a bag.

Technical

In Demandware, this can be achieved by using Product Options. This is the recommended way to deal with monogram in Demandware. As they stated in their document, "product options enable you to sell configurable products that have optional accessories, upgrades...".

We can set up product options by going into Business Manager. Merchant Tools -> Products and Catalogs -> Product Options.

Create a New Option and put in relevant details.


In our scenario, we have allowed up to 3 initials for our monogram. Due to Demandware limitations and our UI design, we decided to store the values in 3 different product options. Each option stores A-Z and a blank, it can vary base on your technical and UI requirement.


We will then create the System Object Attribute to store the Product Options.

In Administration -> Site Development -> System Object Types, we will add new attributes for Product.



Result

Monogramming options can be set at per color level. Therefore, in our product detail page, we are now able to sell our chocolate color bag with monogramming options but not our black color bag.


And the monogram information is available in our mini cart, cart, checkout and all the way through to our order summary page, as well as the order confirmation email that we sent to our customers.

Conclusion

There were a few discussions, considerations and research done within our team when we were planning for the monogram features for our products. Once we read enough Demandware documentations, and with a few try and error in our sandbox, we got our solution. We are happy with this implementations because it uses the native Demandware features rather than putting custom code in our cartridge.

Demandware - Get Active and Upcoming Promotions

Scope

We are trying to get a collection of promotions that are either active or upcoming. We want to pre-calculate all our promotional price in advance for our affiliate feeds, so they will get the most updated price without frequent feeds from us.

At the time of writing, we are using the latest DemandWare 16.7 API.

Technical

In the DemandWare API, there is no such thing about getting active and upcoming promotions. Ideally we would like to return a collection combining the following.

PromotionMgr.getActivePromotions();
PromotionMgr.getUpcomingPromotions(1000);

Since these 2 methods return an object PromotionPlan and there is no supporting methods such as promotionPlanA.Add(promotionPlanB), so we will need to write a bit more code to achieve what we want.

function getActiveAndUpcomingPromotions() : Collection
{
 var promos = PromotionMgr.getPromotions().iterator();
 
 var result : ArrayList = new ArrayList();
 var now : Date = new Date();
 
 while (promos.hasNext())
 {
  var promo = promos.next();
  
  if (promo.active 
  || (promo.startDate != null 
    && promo.startDate > now 
    && (promo.endDate == null || promo.endDate > now)))
  {
   result.push(promo);
  }
 }
 
 return result;
}

Notes

  • Depending on number of promotions in the system, this can be an expensive operation to loop through all the promotions, so it is recommended to use local caching for the collection.
  • Our custom code is better than the original PromotionMgr.getUpcomingPromotions(previewTime : Number) because it was not possible to retrieve ALL future promotions where the previewTime is compulsory.
  • Our custom code only return Collection of Promotion, this is not the same as a PromotionPlan.
  • Beware of the ArraySize Limit 20,000 in DemandWare. Pushing more than 20,000 active promotions to the array will throw exception.

Demandware - Pipeline or start node can't be found.

Scenario

I created a new cartridge called int_fusion_factory. When I tried to run the Pipeline-Start Node pair with a Job Schedule, I am getting the Pipeline or start node can't be found error.



Solution

In Business Manager -> Administration -> Sites -> Manage Sites, there are separated effective cartridge path settings for Business Manager.




We need to add our new cartridge to the Business Manager Path.


Git - How to Handle Emergency Deploy to Live Environment

Master always have our latest changes in our development and could be dirty and not production worthy. In order for us to do an emergency stable deploy to our live environment, it can be achieved as follow.


  1. Suppose we have our Master M. On our last well known tag called mytag deployed to our live environment.
  2. Subsequently C1 and C2 changes are commited to our Master.
  3. And, we have an emergency deployment required for C3 change that needs to be pushed to live with out C1 and C2.
This can be achieved by the following.


# branch out to master-e from mytag
$ git checkout -b master-e mytag

# After committing change C3 to our new branch, we are then good for live deployment.
# Last thing to do is to apply C3 to Master Origin, so that our next deploy will have C3
# This can be achieved by a simple merge.
$ git checkout master
$ git merge master-e

The new branch master-e is then kept until the next master deploy, if we need other emergency deploys before our next master deploy, we can reuse master-e.