Skip to content
Sujan Rokad
● Full-stack application developerEnterprise commerceHamilton, Ontario

Sujan Rokad

is full-stack, literally.

I build and debug enterprise B2B and B2C commerce on Microsoft Dynamics 365: React and TypeScript storefronts, C# commerce services, SQL, and the ERP underneath. When something breaks, I don't stop at the layer where it shows up.

Now
Application Developer, Evenica Corp.
Platform
Microsoft Dynamics 365 Commerce + F&O
Range
React → C# → SQL → X++
Follow the tracesujanrokad44@gmail.com
traceGET /orders?page=1
184 ms
04590135184 ms
  1. L1React
    order-history module
  2. L2CSU
    custom controller
  3. L3CRT
    request handler
  4. L4SQL
    ext view · indexed
  5. L5CDX
    not in path
  6. L6RTS
    not in path
  7. L7F&O
    not in path
Illustrative

The data was synced ahead of time, so the ERP never sees this request.

Fig. 1: The same page, three architectures. Choosing between them is the job.

01The ticket

It starts with one sentence.

Most of my tickets arrive as a business request, not a technical spec. Here's a typical one, and the questions it raises before anyone writes a line of code.

■ User storyState · New

Title

“Show this field on the Order History page.”

Estimate
?
Questions
00 / 13
Layers
0 / 7

Layers in play

  1. Q01

    Where does this data live in Finance & Operations?

    F&O

  2. Q02

    Is it already in the Commerce channel database?

    SQL

  3. Q03

    Does CDX synchronize it today?

    CDX

  4. Q04

    Do we need a new CDX extension to bring it over?

    CDXF&O

  5. Q05

    Or should it come live through the Real-time Service?

    RTS

  6. Q06

    Can an existing CRT entity carry it?

    CRT

  7. Q07

    Will ExtensionProperties do, or does it need a real contract?

    CRT

  8. Q08

    Does it need a new CSU request, response and API?

    CSU

  9. Q09

    How should the storefront module consume it?

    React

  10. Q10

    What caching and query strategy fits?

    CSUSQL

  11. Q11

    What does it cost in performance, and who pays it?

    every layer

  12. Q12

    How does it behave for B2B and B2C accounts?

    ReactCRT

  13. Q13

    How does it get from DEV to UAT to PROD?

    DEV → UAT → PROD

One sentence. Thirteen questions. Seven layers. Working out where something belongs is often more work than the code, and it's the part of the job I enjoy most.

02The stack

Seven layers down.

A Dynamics 365 Commerce storefront is a distributed system. There's a React app at the top, an ERP at the bottom, and services, databases and sync jobs in between. I work in all of them.

  1. L1

    depth −1

    Storefront

    React and TypeScript modules on the Dynamics 365 Commerce SDK: product pages, search, cart, checkout, payments, order history, invoices and account pages. Business copy, limits and feature flags live in Site Builder, not in the code.

    • React
    • TypeScript
    • SCSS
    • Commerce SDK
    • Data actions
    • Site Builder
    • GA4 / GTM

  2. L2

    depth −2

    Retail Server / CSU

    Custom controllers and endpoints on the Commerce Scale Unit, designed around how many calls a page really needs. I rebuild SDK calls by hand in Postman to see what goes over the wire.

    • C#
    • .NET
    • REST APIs
    • Retail Server
    • Postman

  3. L3

    depth −3

    Commerce Runtime

    CRT requests, responses, handlers, triggers and overrides. When the documentation runs out, I read Microsoft's SDK source or decompile the assembly to find where the extension point really is.

    • C#
    • CRT handlers
    • Triggers
    • ExtensionProperties
    • Async APIs

  4. Waterline

    L4

    depth −4

    Channel database

    SQL in the crt and ext schemas: views, stored procedures, functions, table types and extension tables. I write recursive supersession chains, customer eligibility, inventory and order-history queries, and I often translate X++ logic into SQL to check what Commerce will actually see.

    • T-SQL
    • SQL Server
    • Views
    • Stored procedures
    • Query tuning

  5. L5

    depth −5

    Commerce Data Exchange

    Getting ERP data into the channel: jobs and subjobs, scheduler setup, custom synchronized tables and fields, and debugging a sync that has quietly stopped working.

    • CDX
    • Distribution schedules
    • Custom jobs
    • 1010 · 1040 · 1070 · 1150

  6. L6

    depth −6

    Real-time Service

    Live calls into the ERP when the data can't wait for the next sync. Part of the job is knowing when an RTS call per row won't hold up at scale.

    • RTS
    • X++ service methods
    • Batch APIs

  7. L7

    depth −7

    Finance & Operations

    X++ table and class extensions, Chain of Command, and the Commerce setup that everything above depends on: channels, catalogs, assortments, customer hierarchies, trade agreements and functionality profiles.

    • X++
    • D365 F&O
    • Chain of Command
    • Commerce parameters
    • LCS

    200 OK: response on its way back up

↔ All

every layer

Delivery

Across every layer I follow my own changes from DEV through UAT to PROD: Azure DevOps work items, Git branches and pull requests, cherry-picks and reverts, build and release pipelines, Commerce packages and SDK upgrades.

  • Azure DevOps
  • Git
  • CI/CD pipelines
  • Azure Artifacts
  • NuGet
  • LCS
03Case files

Notes from the deep end.

Selected work on production B2B and B2C commerce for Evenica's clients. The client names are left out, but the technical detail is all here.

CF-01

Enterprise industrial distributor · B2B

╱ taken out of the read path

  • CDX
  • SQL
  • C#
  • CSU / CRT
  • React
  • TypeScript
  • X++

Order history, moved off the ERP hot path

Order history and order details were built on real-time calls into Finance & Operations. Every customer page view meant an expensive trip to the ERP, and the new wireframes asked for much more data.

How I approached it
  1. 01Mapped every field in the wireframes to its source ERP tables and joins: sales orders and lines, invoice and packing-slip journals, warehouse shipments and containers, addresses, freight and charges.
  2. 02Designed the Commerce side of a new path: a custom CDX job syncs that data into the channel database, and custom CSU APIs serve it to new storefront modules with pagination and filtering.
  3. 03Checked the migrated data against the wireframes instead of assuming it was complete, and found missing shipment, container, inventory and order-status data before it reached production.
  4. 04Planned the CSU entities and APIs, built the frontend modules, swapped the mock data for real Commerce data, and produced the estimates.

Business wireframes turned into an enterprise data architecture, and the ERP taken out of the read path.

CF-02

Industrial distributor · B2B

  • T-SQL
  • C#
  • CRT
  • CSU
  • React
  • D365 F&O

Selling the right product when the product is gone

Discontinued products are superseded by others, sometimes several levels deep (A → B → C). The storefront had to sell the right replacement from the right warehouse, the same way the ERP decides.

How I approached it
  1. 01Wrote SQL that walks recursive supersession chains together with inventory, warehouse and customer sourcing data.
  2. 02Exposed it through CRT and CSU services to product pages, quick order and the cart, using extension properties where the out-of-the-box contracts stopped.
  3. 03Checked F&O's warehouse-by-warehouse supersession behaviour so the storefront matches the ERP rather than guessing.

ERP business rules reproduced faithfully at storefront speed.

CF-03

B2B invoice payments

  • React
  • TypeScript
  • C#
  • CSU / CRT
  • RTS
  • Site Builder

Paying hundreds of invoices without hundreds of ERP calls

Customers needed to filter invoices (current, past due, paid, unpaid) and pay everything due in one go. One real-time ERP call per invoice falls over when an account has hundreds of them.

How I approached it
  1. 01Built the invoice filters and a Pay all due workflow: eligibility checks, protection against duplicate and pending payments, configurable limits, and cart adds in batches.
  2. 02Made the modal, copy and limits configurable in Site Builder so the business can tune them without a deploy.
  3. 03Designed the API around keeping backend calls to a minimum instead of letting the UI decide how often the ERP gets hit.

Treated a UI feature as an API-design problem.

CF-04

Order templates · platform investigation

  • C#
  • CRT
  • SQL
  • CDX
  • Decompilation

Reading Microsoft's source when the docs run out

Custom fields had to be read and written on order templates, and the documentation didn't say how the platform handles either.

How I approached it
  1. 01Traced the out-of-the-box read path (ProductLists/Search → GetProductListDataRequest → the channel database view) and proved it never calls the ERP, and that extra columns come through as ExtensionProperties automatically. The read side needed far less customization than first estimated.
  2. 02Found that the write path serializes a fixed table-valued parameter inside a sealed class and drops arbitrary extension properties, so I designed another way to persist the fields using Commerce extensions.
  3. 03Later found the cause of a UAT sync failure by comparing replication counters between F&O and the channel database after a PROD-to-UAT refresh.

Reverse-engineered the platform instead of guessing at it.

CF-05

B2B distributor · checkout charges

  • C#
  • CRT
  • RTS
  • X++
  • React

Once per customer, per day

An automatic charge had to apply only once per customer per day, but at the point in the pipeline where charges are calculated, the sales order doesn't exist yet.

How I approached it
  1. 01Worked out exactly when Commerce generates the final sales order and designed the solution around that lifecycle.
  2. 02Sync a one-time-per-day flag, check for earlier charges, suppress duplicates, record the reference after the order is submitted, and tell the shopper why the charge disappeared.

The hard part was timing inside the pipeline, not the code itself.

Trace log

Where it showed up vs. where it lived.

  • SymptomA surcharge showed up at checkout that nobody could explain.

    CauseDecompiled the payment connector DLLs. The surcharge was added after authorization, inside the payment extensions, not in the storefront.

  • SymptomProducts disappeared from search and PDP prices went missing.

    CauseTraced it through customer hierarchies, assortments, catalogs and sync jobs 1040/1150. It was a catalog and assortment problem, not a UI bug.

  • Symptomcatalog=-1 appeared in product URLs, but only sometimes.

    CauseFollowed it into the SDK's product URL builder and found the missing catalog and category context that caused it.

  • SymptomSearch indexing kept failing on large catalogs.

    CauseFixed stored-procedure timeouts, null references and batch failures in a custom Elasticsearch indexer, and made the active-index swap reliable.

  • SymptomCustomers couldn't log in after an environment refresh.

    CauseRebuilt the Azure AD B2C, Commerce shared parameters and F&O Commerce user configuration that the refresh had wiped out.

  • SymptomA carrier weight limit was bypassed now and then on the server.

    CauseFound the timing gap, then hardened the validation on both the server and the frontend, with configurable error messages.

Also shipped

  • Checkout rules for LTL, oversize and restricted freight, with messaging configurable in Site Builder
  • GA4 and GTM analytics carrying customer-account context through Site Builder script modules
  • Backorders experience: X++ RTS methods plus paging, filtering, sorting and ETA calculation
  • Customer eligibility rules traced through stored procedures, sync and view models
  • Contract management pages: status, labor rates, and review and re-sign flows
  • Commerce SDK upgrades across clients: NuGet, Node, Yarn, CSU packages and pipelines
04Principles

How I work.

  1. P/01

    Follow it to the bottom.

    A bug that shows up in React might start in a sync job, a stored procedure, a catalog assignment or a payment connector. I keep tracing until I find where it actually lives.

  2. P/02

    Know when not to write code.

    Someone asked for identical products to merge into one cart line. The answer was a Functionality Profile setting, synced by job 1070, so nothing needed to ship. I check configuration, Site Builder, the SDK, CSU, CRT and F&O, in that order, before building anything.

  3. P/03

    Count the calls.

    Something that works isn't always something that scales. I think in network calls, query sizes, ERP load, pagination, batching and caching before I think in components.

  4. P/04

    Automate the second time.

    If I do the same manual task twice, I write something to do it. That has meant estimate generators, formatting scripts, and a whole time tracker.

  5. P/05

    Translate for the business.

    Estimates, root-cause write-ups, UAT steps, configuration guides: I explain deep Commerce behaviour in language a client stakeholder can act on.

  6. P/06

    Ship it all the way.

    I don't hand code over a wall. I test in DEV, deploy and validate in UAT, and follow my changes into production.

05Projects

Outside the day job.

Dynamics is what I specialize in, but it isn't all I do. I also build full-stack products on my own: for clients, for school, and for myself.

  • Next.js
  • React
  • TypeScript
  • Node.js
  • PostgreSQL
  • GraphQL
  • Drizzle
  • Prisma
  • MongoDB
  • Stripe
  • AWS S3
  • Tailwind CSS
  • Jest
  • Playwright
  • React Native

01Capstone · Mohawk College2025

DesignMyCase

A full-stack commerce platform for designing and ordering custom phone cases. Shoppers upload a photo or pick one from the gallery, crop and position it on a live device mockup, choose model, material and finish while the price updates, and pay with Stripe. Behind it is a full admin side for running the store.

  • Admin dashboard with revenue and order analytics, customer roles and bans, catalog and image-library management, and moderation of shared designs
  • Email OTP verification, Google sign-in, saved designs, favourites and a daily reminder job
  • 215 tests across 44 suites (Jest and React Testing Library) plus Playwright E2E in CI
  • Next.js 15
  • React 19
  • TypeScript
  • PostgreSQL
  • Better Auth
  • Stripe
  • AWS S3
  • TanStack Query
  • Zod
  • Jest
  • Playwright
sujan-capstone.vercel.appSource in a private college repository.

02Client website2025–26

Orbis Valves Industries

The website for an industrial valve manufacturer in Ahmedabad, India: a product catalogue with material and specification tables for every valve, an industries section, a brochure download, and inquiry forms. It's built with Next.js and exported as static HTML so it runs on the client's shared hosting, with clean URLs and no server.

  • Data-driven product and spec pages generated from typed content
  • Static export tuned for LiteSpeed shared hosting, with no rewrite rules needed
  • Per-page metadata, sitemap, Open Graph and local-business SEO
  • Next.js
  • React 19
  • TypeScript
  • Tailwind CSS 4
  • Framer Motion
  • Zod
orbisvalves.comsujan-22/orbis

03Client website2026

Rovanta

The website for a specialty chemical manufacturer in Gujarat that makes copper compounds (copper oxychloride, oxide and sulphate) and agrochemical and pharmaceutical intermediates. Product pages carry formulas, CAS numbers and specifications, and buyers can request a quote from any of them.

  • Editorial design system with a copper-and-verdigris palette taken from the products themselves
  • Organization JSON-LD, geo data, canonical URLs and per-page metadata for B2B search
  • Content kept in one typed source, so the client's facts are changed in one place
  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS 4
  • Motion
  • Vercel
rovantachem.com

04Personal tool2026

Meridian

A quarter-hour time tracker I built because I kept piecing my Friday timesheet back together from memory. It has a timer, a drag-and-resize week calendar, Google Calendar sync, hours per ticket against the original estimate, and a timesheet screen that prepares the whole week for submission.

  • Code-first GraphQL API (Pothos + Yoga) with generated, typed client operations
  • Raw timestamps stored exactly, with billable quarter-hours derived from them so rounding never loses data
  • Toggl CSV import that skips entries it already has, so re-running it is safe
  • Next.js 16
  • TypeScript
  • GraphQL
  • Apollo Client
  • Drizzle ORM
  • PostgreSQL
  • Better Auth
sujan-22/meridian

Archive 2023–2025

All repositories
  • 2025
    Polaris Store · Multi-vendor store with seller and admin dashboards, order tracking and Stripe payments
    Next.js · Prisma · MongoDB · ZustandLive Code
  • 2024
    RoboCase · The first phone-case designer, the prototype the capstone grew out of
    Next.js 14 · Stripe · TailwindLive Code
  • 2024
    Airbnb clone · Listings, bookings, favourites and authentication
    Next.js 13 · Prisma · MongoDB · NextAuthLive Code
  • 2024
    Night Owl · MERN e-commerce with auth, search and cart
    MongoDB · Express · React · NodeLive Code
  • 2024
    Realtime chat · Mobile chat with presence and live updates
    React Native · FirebaseCode
  • 2024
    Movie browser · Discover and search films from the TMDb API
    React Native · RESTCode
  • 2024
    Competitive programming · Codeforces solutions across difficulty levels
    C++Code
  • 2023
    HTML tag checker · Desktop tool that checks whether HTML tags are balanced
    C# · .NETCode
06Record

Co-op to full-time.

I joined Evenica as a co-op student in 2024. They kept me on part-time while I finished school, and I went full-time in December 2025. My scope has grown every term since.

Evenica, Sep 2024 → today25 months and counting
Co-opPart-time + schoolFull-time

  1. Dec 2025 → now

    Application Developer

    Evenica Corp. · Burlington, ON

    Full-time on enterprise B2B and B2C commerce for Microsoft Dynamics 365 clients. My work now includes architecture investigation, backend Commerce and F&O integration, channel-data design, estimates, client-facing analysis, release management, and walking newer teammates through CDX, CRT and the Dynamics build.

  2. 2025

    Application Developer, part-time

    Evenica Corp. · Burlington, ON

    Evenica kept me on after the co-op while I finished school. By then I was implementing substantial client features on my own and debugging production issues.

  3. Sep 2024

    Application Developer, Co-op

    Evenica Corp. · Burlington, ON

    Joined on live client implementations rather than student projects, and learned the Commerce SDK, CSU, CRT, F&O and Evenica's architecture on real tickets.

  4. 2022 → 2025

    Computer Systems Technology, Software Development

    Mohawk College · Hamilton, ON

    Data structures and algorithms, databases, web and mobile development, .NET, Java and Python. Capstone: DesignMyCase.

07Bedrock

You've reached the bottom of the stack.

Most people stop at the surface. If you need someone who won't, whether for a role, a project, or a bug that crosses too many layers, I'd like to hear about it.

sujanrokad44@gmail.com

Based in Hamilton, Ontario, Canada