If your DL Freight account is locked, please send an email to [email protected] to access your account.
An activation link is sent to your registered email address. Click on the activation link to access the DL Freight platform. Contact your organization's assigned representative/Admin to receive an activation link. NOTE: The activation link is valid for 48 hours.
[Including but not limited to login failures, successes, account lockouts, etc.]
Successful and unsuccessful login attempts trigger the application to capture details like the number of unsuccessful attempts, ID used for gaining access, Date and time, IP address, Region, and Account status (active, inactive, de-active, or locked). These details can be updated per the client's request and approval from the DLT Labs Security team.
[This query includes moving, adding, changing, and deleting user accounts.]
The operator account can administrate the user accounts under it. This account is the parent account and is under the client's access. The operator account can – change accesses – activate and deactivate users – and edit user details.
The platform supports authentication features such as Password Complexity, Password Re-Use, Session Timeout, Account Lockout, Password Reset, Multi-Factor, etc.
The user will have to hit the webhook "
The Digital signatures can be attached to the forms where required. After reviewing the required details, an entity receives an instance; the acceptance can be approved. On approval, the user's digital signature reviewing the details will be attached to the record and stored on the Digital Ledger.
If the user wants to revoke the approval, then the digital signature available on the records will no longer be valid. The condition for validation of the digital signature will involve approval of the details shared and the availability of the signature. If the latter is missing, the signature will not be considered an approval of the details.
The Fabric users and secrets are created at the user creation process initiated by the Platform Admin or Operator.
The platform will not allow any inaccurate information to be mined. It works and authenticates/authorizes strictly based on OIDC and OAuth2.0 protocol.
The consensus mechanism will ensure that the entered information has the consent of all the nodes.
Asset Category's name and description can be edited. The asset category cannot be deleted.
Find out more about Asset Categories.
The trigger information would be the events that will initiate the automation processes. Any data with a definite value or a range of values can cause an automated trigger in the platform. Information like names, phone numbers, and security numbers can be used to trigger automation in the platform.
The business workflow does not support circular dependency. If the system finds one, it will not allow the workflow to be saved.
A business workflow will end when it reaches the expiration date. You have another option of deactivating the business workflow if required.
Learn more about managing Business Workflows
Branching can be achieved using connectors. This is available at the time of workflow creation. How to create and configure a Business Workflow? – Let's find out!
Considering the client is concerned if there is maintenance access from specific countries.
There won't be any maintenance access as when the client buys the cloud storage, the cloud companies like AWS, etc., will ensure complete access to the client and the information stored within it.
DLT Platforms are well equipped, and the information is access controlled. This means the platform can be controlled by who can view and who cannot view the content/information. The information is available only to authorized personnel/groups as per the business requirement.
IAM = Identity Authentication Management.
DLT manages the platform, which manages the Operators, which manages the Participants. DLT follows strict authentication guidelines according to ODIC and OAuth 2.0 protocols. AWS IAM key or any cloud access and identity management have no linking to the roles and access of users on the platform.
Operators are the brains, the governing body of the platform. They configure the platform. Participants execute the workflow. For now, permissions are group-centric but eventually will be participant-centric. Operators determine what a participant can view and what they can edit, and operators also design and define the code chain on Fabric.
The DL platform supports Role-based access for various users. The access permissions are statically defined in the product for those fixed roles we support.
The chaincode in the fabric is entirely managed by the network admin. No other user has permission to deploy, install, or instantiate the chain code.
There are seven user roles associated with the DL Platform to meet the functional requirements. The associated user roles are:
1. Platform Administrator
5. Data Operator
To achieve HA (High Availability) on the DL Platform for DL services, follow the steps below on the architecture and monitoring front.
Currently, there is a logical separation of users done at the DL-Layer based on which tenant (operator) they belong to. For the ASIK layer, multi-tenancy is introduced. At present, all the users co-exist in a single space.
Branching can be achieved using connectors. This is available at the time of workflow creation.
The Byzantine Generals Problem describes the difficulty decentralized systems have in agreeing on a single truth. The Byzantine Generals Problem plagued money for millennia until the invention of Bitcoin. Bitcoin uses a Proof-of-Work mechanism and a blockchain to solve the Byzantine Generals Problem. Find out more about Byzantine General's Problem in this blog.
A vital component of the DL Platform is its modular design. The multi-layered architecture is interchangeable, allowing you to pick the functionality your organization needs and incorporate additional features and functionalities as your business evolves.
The platform can be arranged to suit:
Each module can function independently and seamlessly integrate back with each other through product configuration when needed.
Modern business network workflows are inherently complex. Whether it is the tendering of shipments to different carriers, resulting in different business rules, or tracking and tracing commodities shipped via different modalities (land/sea/air), maintaining accurate records of these transactions remains challenging.
Out of the box, though, DL Asset Track supports the ability to configure workflows with conditional, non-linear, and complex paths within a powerful and feature-rich enterprise admin console. It is defined by its unique ability to simplify complex business processes by reducing or altogether eliminating unnecessary steps. For example, leveraging smart contracts and master tables (i.e., contracted rates) can eliminate audit cycles as the platform enforces compliance with these contracts – all achieved with minimal code intervention through the enterprise admin console. Additionally, the console allows the user to define workflow attributes and business rules within tested, production-ready selectable validations.
The DLT platform is both industry and business case agnostic, i.e.; it’s not restricted to operating within the confines of specific verticals or proprietary technology. The platform's democratized accessibility works brilliantly across various sectors, from logistics and supply chain management to financial services and raw materials tracking.
We will give you a complete extract of all your data stored on the blockchain, which you can upload wherever you wish.
The callback can be configured from the participant's account. When you log in to the platform and go to the workflows, you will see two icons on the top right. One is for generating credentials and the other for a callback.
To receive updates from an external source, we have a set of exposed APIs. The external source can use those APIs and send the information to DL Asset Track.
To send updates to an external source, we have exposed the service node when configuring a workflow. This node has a POSTMAN look-alike configured within it. We can use this to send information to the external source by calling their APIs.
Explore the product documentation to configure callbacks and authentication.
A wide variety of integrators are available:
The data is written to state DB(in this case, Couch DB) based on events generated in the system. Every transaction produces an event and will thereby trigger data writes to state DB. The data write operations are done by a pre-configured service account (by the system) and don't have any direct access to the users.
The off-chain and on-chain information are determined at the time of final requirement gathering. We can confirm that all PII data will not be on-chain to comply with the regulations such as GDPR.
Here are the data storage criteria – Usually, critical and transaction-related data will be stored in the blockchain, and other business-related data will be processed at the DL Layer. Some of the following will help.
The following is the integration diagram which will give you the required information about DL Platform and its integration with 3rd party systems and devices.
DL Asset Track uses a completely distributed network topology where each VM is distributed across various data centers or zones.
All VMs are deployed using the Kubernetes technology. Therefore, the specification of the VMs is irrelevant. Recommend configuration values are stated below. The recommended values may change depending upon further discussions during the requirement phase.
Server Capacity Requirement (OD – Centos7.x/Amazon Linux):
2VM'S (DL Web Servers) – No. of Cores: 4, Memory: 8GB
2VM'S (ASIK Web Servers) – No. of Cores: 4, Memory: 8GB
2VM'S (IAM Auth Web Servers) – No. of Cores: 4, Memory: 8GB
3VM'S (MongoDB Servers) – No. of Cores: 8, Memory: 32GB
2VM'S (Postgres Servers) – No. of Cores: 4, Memory: 16GB
4VM'S (Zookeeper Kafka Servers) – No. of Cores: 8, Memory: 16GB
2VM'S (CA Servers) – No. of Cores: 8, Memory: 16GB
3VM'S (Orderer Servers) – No. of Cores: 8, Memory: 16GB
3VM'S (Peer Servers) – No. of Cores: 8, Memory: 16GB
3VM'S (CouchDb Servers) – No. of Cores: 8, Memory: 16GB
There are a series of steps taken to protect the data and remove the security concerns. These are steps as follows:
Authentication Layer where the protocols redirect users to enter their credentials with verifiable assertion.
- Channels allow for logical segregation of the blockchain where only permissioned users can see assigned data.
- Adding /removing participants from the network is more accessible and less costly, as they will be added through a centralized (and permission) administration panel.
- The platform captures all the activities and logs for the authorized participants to view.
- The authorized team can provide access to the blockchain explorer for audits and logging purposes.
Possible. But will be allowed after approval from DLT Labs security team.
Vulnerability disclosures will be provided to the client via email. These emails will be sent to the authorized email IDs provided by the client. The results will detail the vulnerability to the extent of how it was caught, what caused it, and the solution.
The DL Platform undergoes regular security checks. In case of any vulnerabilities are found, the security patches will be provided post thorough testing and checks, ensuring zero risks. DLT Labs will deploy the patches with the help of the client's security team with zero downtime as all deployments are containerized.
A checklist for securing and hardening the environment and platform will be provided with the updated test results and suggestions.
This checklist will compromise handling:-
-Management of Platform Access
- Minimizing external footprint
- Patch vulnerabilities
- Minimize the attack surface
- Restrict admin access
- Check on user access permissions
- Hardening and protecting credentials
- Backup Plans
- DR Management
• It is basically, password authentication for all the users using the UI for interaction and accessing the platform and is session cookie-based access thereafter.
• The same is the case for Mobile users.
• If the interaction is a backend application, it is based on OAuth. Essentially, we provide a ClientID & secret for each application to generate a token and interact with our APIs.
Key area while creating and configuring a Business Workflow on DL Asset Track, the auth feature "provides secure identity authentication for all users of the proposed module".
The Digital signatures can be attached to the forms where required. After reviewing the details shared, a group receives an instance; then, the acceptance can be deemed approved. On approval, the user's digital signature reviewing the details will get attached to the record and get stored on the Digital Ledger.
Certificates can be verified by the unique transaction hash and or QR code which are just two separate forms of representation on the blockchain. The configuration on the platform allows the user to select any one of these options. Verification by transaction hash can be done via the public website, the authenticated state, and the mobile app. A mobile app can verify the QR code.
Certificates compromise of attributes. These attributes include the participant’s name, issue date, valid date, course name, and grade. In addition, several customized attributes can be added to a certificate. The certificate has an immutable representation on the blockchain, which is the basis for validating; however, all the attributes are not put on the blockchain due to protecting PII data. All non-PII attributes sit on the blockchain, whereas PII attributes are stored off-chain, and their representation (hash) gets stored on the blockchain to make it immutable.
All the data on-chain is signed & encrypted at rest or in motion by a certificate owned by the owner of the data, and there is no way anyone else can decrypt it. This is how the platform ensures all data on-chain are safe & secured.
As the data is stored and managed on the cloud, the responsibility will be with the client owning the cloud. Ideally, in this case, where it is the client's data, and the access is with the client, it is assumed to be the client company responsible for information leakage.
If this leakage happens from the system, it will leave a footstep behind as everything is captured on Blockchain and immutable.
You can check the audit trail using the portal or API's Comment & Activity Log feature.
Find out more in the Activities & Comments section on the product documentation page.
All the transactions occur over a permissioned and private blockchain network assigned/facilitated for the enterprise. And each of the transactions has a unique id that can be verified and accounted for within the network. Any changes or modifications are treated as transactions that cannot be erased or edited. Additionally, the blockchain network has an immutable ledger that stores the transaction record updating it simultaneously with all the peers/nodes in the network in the intervals of minutes. The concept of Byzantine’s General problem would be the best example of how the secure network works and is immune to tampering.
The unique transaction ID is available for each workflow instance on the DL Platform. Access the transaction ID by selecting the required business workflow. Identify the instance that you need to verify the transaction. Click on the View Details button of the workflow instance. From the details page, select the Blockchain/Platform Logs option. This window provides the details of all the transactions in the selected workflow instance.
The smart contract/chaincode version is controlled by ASIK.
Versions for product releases and patches are managed by the business and delivery management team from DLT Labs.
The platform is based on the core concept of the supply chain, where before exchanging any Asset, the organization must first carry out a handshake. Once the handshake is done, only then should an organization be able to send an Asset. The other organizations should be able to confirm that it has received the Asset. This is the basic principle of communication which says communication is always bidirectional. One-way communication will primarily result in a dispute. DL Asset Track ensures all the communication within the organization is always bidirectional.
Walmart collaborates with thousands of organizations to make sure all their stores have enough goods. Among all other collaborations, the one partnership which is the most important for Walmart is the one with carriers. The carriers are Walmart’s supply chain backbone. Therefore, they wanted to make sure carriers could have the best o the relationship with them; in other words, Walmart wanted to make sure carriers trusted them. In our view, there is no better technology than Blockchain to improve trust among organizations.
DL Asset Track is exceptionally flexible and can be changed anytime to meet new business needs. The system is designed to upgrade a Business Workflow, then make a copy of the Business Workflow, upgrade it, and replace it with the old Business Workflow. We have done it to make sure the owner of the Business Workflow doesn’t end up updating the live Business Workflow without notifying all the other Business Partners on the network. This behavior of the platform can be changed for a tenant, but it’s not recommended.
If a Quick Pay contract is agreed upon between Walmart and Carrier, then the Carrier information is communicated by Walmart to DL Freight. Within DL Freight, the carrier details are captured. When an invoice against the respective carrier is generated, the system ensures the following points with the help of smart contracts.
DL Freight can cater to Quick Pay options in multiple ways depending upon the business rules and contracts between two parties: Scenarios could be the following:
All invoices of a particular organization can be considered for Quick Pay.
Invoices ranging between specific monetary values can be considered for Quick Pay.
Invoices generated between specific dates of a month/cycle can be considered for Quick Pay. Likewise, there could be other options too.
Below is the snapshot of DL Freight with the Quick Pay option enabled against one of the carriers. These are not manually entered for every invoice but calculated by the platform based on smart contracts.
When editing an expression as an operator, the latter can see the child expressions on which the master expression is directly dependent. Also, in case of dependency of any expression on other expressions, which results in a deadlock, such circular dependencies are alerted by the system and prevent the operator from making such mistakes. Find out more about Expressions.
Select the required Business Workflow after successfully logging into the application. Upon selecting the required workflow, an instance/shipment listing page appears on the screen that contains all the shipments or workflow instances. On the listing page, you can search for a specific instance/shipment in the following ways:
When a load ID is expected but doesn’t appear in the DL Freight portal, the most common cause is that it has not reached a status of “ACCEPT” in the Walmart TMS (WTMS).
The carriers must respond/revert to Walmart’s EDI 204 and EDI 990 in the tender process to ensure this. Contact your Walmart representative and have them manually accept it in their TMS on your behalf.
You can raise a dispute on these, and Walmart will update their Toolkit. DL Freight application will, in turn, receive the updated rate and automatically recalculate your invoice.
Explore how to raise disputes on DL Freight - Dispute Management
Carriers are heavily motivated to get on board with the platform as they get paid much faster by using the DL Asset Track Platform than using the old system.
Carriers are the peers.
The return on investment for Walmart has been enormous. An extremely conservative estimate is 10x ROI which would not have been possible without using blockchain. One of the main reasons is without trust in the system, no carriers would have agreed to put their data onto the platform.
The ROI calculation is both vital and complex. It is inter-departmental, which helps have departments aligned and committed but has comprehensive before and after information that requires working with each department. There are confidentiality concerns, so further review and discussion of savings/ROI and new revenue are under NDA only.
The goal was to configure a system that provided a much deeper level of insight into the retailer’s invoice, reconciliation, and payment processes. For this to be successful, we had to start at the very beginning, which meant an end-to-end audit of the interlinked processes of the enterprise. While this represented a lengthier approach, the result allowed us to configure a solution that tackled the major challenge head-on and meant that there were no surprises affecting future enhancements.
This end-to-end approach enabled us to:
The DL Platform has evolved in the following areas: