Adobe Consignment

The diagram below represents how an update from Fluent is processed in Adobe.

Consignment webhook

Configuration

The settings below demonstrate how the handler is mapped to a Fluent Webhook message name. It is possible through Adobe’s dependency injection to add more or even override the default settings.

`1 <type name="FluentConnector\General\Api\WebHook\HandlerFactoryInterface"> 2 <arguments> 3 <argument name="handlers" xsi:type="array"> 4 <item name="ConsignmentStatusChanged" xsi:type="string">FluentConnector\Consignment\Handler\ConsignmentHandler</item> 5 </argument> 6 </arguments> 7 </type>`

Validation

There are a few different validations executed before the actual webhook processing begins. These validations are part of a validation chain configured at di.xml as follows:

`1 <virtualType name="consignmentValidatorChain" type="FluentConnector\General\Model\WebHook\MessageValidatorChain"> 2 <arguments> 3 <argument name="validators" xsi:type="array"> 4 <item name="consignmentEnableValidator" xsi:type="object">consignmentEnableValidation</item> 5 <item name="consignmentEntityTypeValidator" xsi:type="object">consignmentEntityTypeValidator</item> 6 <item name="orderStatusValidator" xsi:type="object">FluentConnector\Consignment\Model\WebHook\Validator\OrderValidator</item> 7 </argument> 8 </arguments> 9 </virtualType>`

Some of the validation includes:

• Fluent account details are aligned with the configuration in Adobe 
  • accountId
  • retailerId 
• Webhook entityType is CONSIGNMENT
• Order reference exists in Adobe

Processing

The webhook execution simply adds the message to a queue to be processed asynchronously.

Topic name: `fluentcommerce.consignment.updater`

Message content:

• retailerId (retailer id)
• entityId (Fluent consignment Id)
• rootEntityRef (Adobe order increment ID)

Consignment Processing

The extensions use Adobe's standard approach to process items waiting in a queue. The diagram below illustrates the sequence of events for each queued item.

• Consume messages from the queue 
• Fetch consignment entity by ID from Fluent including articles
• Run initial validation to make sure this consignment and fulfillment are related to our orders and order items
  • order exists and matches the queued item
  • order item exists in the platform
  • order items are available for shipment
• Create order shipment for fulfillment items (partial or fully shipped) 
  • Use Command patterns for data processing if the consignment status matches the configuration
• Adds a shipping tracking code
  • use Command patterns for data processing
  • Tracking code can only be added to existing shipments

The actual processing is done through commands which can be overridden or extended by Adobe’s dependency injection only.

`1 <virtualType name="consignmentProcessCommandPool" type="FluentConnector\Consignment\Model\Command\CommandPool"> 2 <arguments> 3 <argument name="commands" xsi:type="array"> 4 <item name="shipment" xsi:type="string">FluentConnector\Consignment\Model\Command\Order\Shipment</item> 5 </argument> 6 </arguments> 7 </virtualType>`

Consignment vs Shipping Field Mapping

Module Architecture

• FluentConnector/Order/Handler/ConsignmentStatusUpdateHandler.php
• Handler to publish Consignment messages to the message queue 
• FluentConnector/Order/Model/MessageQueue/Consumer/Data/ConsignmentUpdateMessage.php
• Data interface for the Message queue message
• FluentConnector/Order/Model/MessageQueue/Consumer/ConsignmentUpdateConsumer.php
• Consignment update Consumer 
• FluentConnector/Order/Model/Command/Order/Shipment.php
• Order item status update command
• FluentConnector/Order/Model/Command/Order/ShipmentTracking.php

Consignment Events