Foolad 24 is a marketplace for Iron and Steel products - to connect sellers and buyers together. The goal of the website is to bridge the gap between sellers and buyers of iron and steel products in micro (C2C) or macro (B2B) scales. Service Providers register on the site and can create Products, Auctions, RFQs, Tender Sales. There are various intricate interactions between these three components, and a detailed membership module delegating permissions based on membership levels. Also the site needed to be fully bi lingual, in Farsi (RTL) and English.
About the project
Project Goals
The goal of the project was to create a marketplace for Iron and Steel products. The Service Providers will be able to register, and create their profile. Once done, they can create products, RFQs, Auctions and Tender Sales. Buyers can come and search these, and contact the sellers directory through call/chat. If they need to place the bids on the RFQs or Auctions, they need to create an account in the site. The sellers will need to subscribe to membership levels and based on that, they would have certain access to certain features of the site. This is Phase I of the project which we completed. There are 3 more Phases to this, which we are working on, which includes email / SMS based notification alert and custom subscription creation, full blown E-commerce and marketplace feature and Social Media Integration. We needed to keep this in mind while building the structure and the background work.
Project Requirements
The major requirements of the site can be mainly grouped into the following:
User Account Creation & Registration Mechanism
Users should be able to create accounts. We had to replace the email based registration system to a phone number based registration system. The users need to add their phone numbers and OTP will be sent to them. Once they add in the OTP, they will be asked to set their password and get in. To change the password also, they need to add in Phone Number and validate the OTP. We used Twillio as OTP service for the supported countries, and used a private SMS service for Iran, which the client preferred. Once in, users can set their profile data and can use start to create products and other entities.
Products
This is the main building block of the other entities - RFQs, Tender Sales and Auctions. User needs to add at least one product before they can create other entities. The product had a huge number of specification fields, and they needed to organised as cleanly as possible. We employed Field Collection, Field Collection tables and host of other modules for this, in total we had around 46 fields to be created in the product content type itself. We also employed google Maps and reverse geocoding for the Load Location field.
RFQs
Sellers could then, once they had added some products, create RFQs or Request for Quotes. This had a complicated feature of either choosing a product, or be able to custom product right in that content type, which needed to be multivalued. Main complication was that the number of fields were huge, around 46. We solved this problem using Inline Entity form and Field Collection AJAX modules. The RFQs also had an end date, and users could bid on the RFQ till the end date. The RFQ bid feature was implemented using the comments entity on the RFQ node and a few custom tables to track pricing.
Auctions
The Auction feature had all the features of normal auction. Sellers could create auction and mention the products he wants to auction (that the seller created). He would also mention an end date of the auction and a base price. The users will then bid on the auction. This bid feature was fully custom implemented, and users can only bid an amount that is greater than the last bid. At the end of the timeframe, the user with highest bid amount will be the winner.
Membership Feature
We used membership Entity as the base for this feature and then extended the work through our custom modules. The membership Entity module declares everything through Entity API making it very much extendible. We implemented additional permission checks and associated roles to award and revoke membership. Also, the membership page is integrated to registration. As user sets their password, they are taken to membership page, asking them if they would subscribe. They have the option to skip this step though.
Private Chat
The chat feature was implemented using the Drupalchat module. We used the code and forked the module to add our necessary customisations. Need to heavily customise it, but nevertheless the base work has been very helpful and time saver. In Phase II plan is to use nodejs and the chat driver, right now it's using ajax polling method.
Outcome
The project was extremely complicated. It had lots of layers and main challenge was to keep it steering ahead without creating logical blobs for us. The architecture needed to be very robust to be able to handle the features of not just this phase, but also upcoming 3 Phases, which the client has already briefed us beforehand. We did careful planning and divided the tasks into sprints. Each and every architectural decision was carefully evaluated ensuring it will play well long term and it will not conflict with a future solution that we need to implement. Eventually all turned out to be good, and the client was extremely happy with the functionalities, backend and overall communication and responsiveness of out team. The project was a success! Time to get moving with the rest of the phases which we are already into.
Why Drupal was chosen
Well, considering the project requirements, which was heavily feature rich, Drupal was definitely the framework of choice for us. This project needed extremely complicated features like Product Creation and Inventory Management, Auctions, RFQs and Tender Sale features. Even though there were not many out of the box modules for this, but Drupal APIs and it's architecture would have definitely helped. Client had heard about Drupal, but was unsure if it would be a good choice. We met with them and explained the benefits and once they did some research themselves, they saw the value in this and promptly gave us the go ahead.
Technical Specifications
Drupal version:
The main features of the site Products, RFQs, Auctions and Tender Sale were all handled custom. We created content types and utilised Drupal fields architecture for this in addition to using modules like Field Collections and Field Collection Tables. The bidding process employs Node Comments and this is perfect example of the power Drupal bring in with just it's core.
Another important thing we needed to do was translation. We employed good old i18 suite of modules but for translating taxonomies and nodes, instead of the i18 we used entity translation module. This was far better approach according to us, and helped us a lot to give a lean flow ton the translation mechanism.
Apart from that we did extensive work on search API and SOLR for the site search and employed Facets to give a smooth searching experience.
But apart from the contrib modules, we employed core APIs to it's fullest, like Forms API, AJAX API, Fields API and finally the Views API to do various query alters and customisations.
