Marketplace
General Description
The Marketplace primarily targets users from the manufacturing sector. The successful concept of the App Stores for mobile platforms is transferred to the domain of the manufacturing sector, where specialized applications (zApps) in combination with the ZDMP platform result in easily deployable applications for various kinds of use cases and all kinds of infrastructure need a central repository for zApps.
The Marketplace fills this need by enabling users and administrators of manufacturing companies to search for existing applications based on many characteristics such as category, price, type of payment (demo applications, one-time fee, pay-per-use, monthly or yearly licenses, etc) and obtain licenses for their company. The purchase process includes the entire flow of selling: negotiation, order, invoicing, payments, post-selling services like technical support and keeping tracking of application usage. For users, a collaborative system for presenting ideas and requests towards 3rd party developers is included so that users can make clear what kind of solutions they are currently missing, stimulating developers to create more zApps. In addition, users can rate and review zApps as well as view existing ratings and reviews added by other users.
The backend provides 3rd party developers a content management system for organizing and populating metadata for the different applications. The different possible licenses as well as the pricing can be managed in the backend, and also managing in-App advertisements and affiliate marketing is possible.
| Resource | Location |
|---|---|
| Source Code | Link |
| Latest Release (v1.0.0) | Link |
| X Open API Spec | Link |
| Video | Link |
| Further Guidance | Link |
| Related Datasets | None |
| Additional Links | None |
| Generation date of this content | 07 May 2021 |
Screenshots
The following images are illustrative screen shots of the component.
Component Author(s)
| Company Name | ZDMP Acronym | Website | Logo |
|---|---|---|---|
| Software Imagination & Vision | SIMAVI | www.simavi.ro |  |
| Ascora GmbH | ASC | www.ascora.de |  |
Commercial Information
| Resource | Location |
|---|---|
| IPR Link | Marketplace |
| Price | [For determination at end of project] |
| Licence | [For determination at end of project] |
| Privacy Policy | [For determination at end of project] |
| Volume license | [For determination at end of project] |
Architecture Diagram
The following diagram shows the position of this component in the ZDMP architecture:
Figure 46: Position of Marketplace Component in ZDMP Architecture
Benefits
The marketplace user interface and payment system provide several benefits. zApps can be explored by categories and using a search, and zApps can be rated, reviewed and new zApps can be requested. The user can also view licenses they bought. The shopping cart makes the payment procedure usable and effective, collects the necessary user data, triggers the purchase, and notifies the License Manager when a user has obtained a license for a product.
The License Manager provides the backend to create and update zApps and their respective licenses, including pricing. License subscriptions will be managed as single one-time purchases. In these cases, the user will be notified, that they have to obtain an updated license. Licenses can be managed, renewed, and cancelled (beginning with Milestone 3).
In addition, affiliate links can be created, and sales generated with these links are aggregated on a per product and per user basis.
Features
The features for this component are itemised below and explained there after:
Marketplace User Interface and Payment System
Product and License Manager UI and API
Affiliates Manager UI and API
Marketplace User Interface and Payment System
The functions for the Marketplace, including its User Interface and Payment System, which have been created, are as per the following:
Shopping cart: The shopping cart functionality is shown in Section How to use
Visual UI Adaptation: Styling towards ZDMP or i4FS in terms of colours and corporate identity was prototyped in the application available on the webserver and is also reflected in the screenshots of Section 2.2and 2.11.1.
Rating and Review of zApps: The basic functionality was created but was not yet extensively tested
Affiliates management: A basic version of the planned Affiliates management system was implemented and is shown in Section 2.7.3
Requests: Research and implement application request / proposal system for the marketplace: a separate tool named Fider is used for this. Screenshots and usage are shown in Section How to use
Choose / Explore Categories: The feature is mostly implemented but not yet finished, as the categories need to be adapted to Categories useful for ZDMP
Marketplace Search: The search is implemented but is currently only searching in titles and not in content
Explore Marketplace: This feature is also not marked as done yet, as some of the other features which count as exploration of the marketplace are not yet finished
Product and License Manager UI and API
The Product and License Manager a simple content management system to manage the static information about software (zApp) products. This is a backend UI in order to easily manage the content behind this, showing of the content is done in the marketplace frontend.
The functions and features of the Product and License Manager component are the following:
Integration with the Secure Installation in order to add a security layer over model training process
UI for users to manage product (CRUD), translate and review them
UI for additional data useful for products such as: Supported platforms, license types, version purposes, tags etc
Manage the license management, send emails for to users regarding their license status, verify the license purchase etc
Affiliates Manager UI and API
The Affiliate Manager feature generates referral links which can be used to trace the source of the licenses sales. The UI displays the total sales per referral link which allows the user to know which product generated more sales and where the sales were generated. The system is tracking this information in order to be able to pay bloggers or social media marketeers who have brought paying users to the platform, which is a basic means to improve external interaction and word-of-mouth marketing, and which is a successful concept that was a cornerstone of the business success of online retailer Amazon.
System Requirements
Minimal requirements needed:
Virtual machine with at least 4 VCPU, 16GB RAM and 80GB of disk
Docker version 19 minimum
Associated ZDMP services
Required
Installation
Installation Marketplace User Interface and Payment System
The marketplace user interface currently cannot be built and complied on the ZDMP infrastructure. The reason is that there is proprietary code involved which is not open sourced, but currently tightly coupled within the marketplace frontend. Therefore, the code cannot be fully opened to a project internal source code management (SCM), and also cannot be built in a project-public continuous integration system. A future release of the marketplace will enable the frontend and the backend to be separated cleanly, in order to have the payment system only deployed on a Cloud instance while the rest of the system can also be integrated in a local installation at a manufacturing site for example.
Currently, the code for the marketplace is developed internally at Ascora and also managed via GitLab. If there are changes in the source code and a new release is tagged, this code is automatically built and deployed to this URL: https://zdmp-marketplace.ascora.de/ . The marketplace is hosted on Ascora’s servers to maintain the privacy of the proprietary code. For future local instances of the Marketplace, a version disconnected from the shop system (which contains the proprietary code) is planned, so that a federated instance can work on local premises while payment requests have to be redirected to a global instance connected to the public ZDMP infrastructure, but still running on Ascora servers.
Installation Product and License Manager
After the Docker containers are ready for use, run the commands to below have the system ready for use.
This command runs the composer command in order to download the PHP packages needed for the project:
docker exec –it orchestration_product-license-manager sh -c " composer install"Figure 47: Installation Product and License Manager (Docker shell)
This command runs the composer command in order to create the database tables and populate the tables with the necessary data such as: Languages, supported platforms, license types:
docker exec -it orchestration_product-license-manager sh -c "php artisan migrate --seed"Figure 48: Create database tables and content (Docker shell)
This command creates the .env file which is the base configuration file for Laravel. Without this file, the component will not start:
docker exec -it orchestration_product-license-manager sh -c “cp .env.example .env”
Figure 49: Create necessary environment (Docker shell)
How to use
Marketplace User Interface and Payment System
Marketplace content is displayed in the following screenshot:
Figure 50: Marketplace start page for logged in users
The frontend for users focuses on findability of the created zApps. For this, the following tools are implemented:
A sorter allows the sorting of the shown list by Category, Price, Name or Rating. It is planned to expand this by date created and date updated
The categories on the left-hand menu let the user quickly filter by Category. The discover mode lets the user search for a flat list of all categories of zApps. These categories are obtained from the Product License Manager
The search bar allows filtering the results shown by title, dynamically updating as necessary. It also includes search suggestions based on matching product titles
To view and interact with the Marketplace user interface, the user is required to be registered and logged in using the ZDMP user management functions. Otherwise, they will be redirected to the ZDMP Portal.
Figure 51: zApp Detail Page
The single items are now comprised of a title, version information, categories, screenshots, a screenshot gallery, a description, a list of dependencies, a ratings widget displaying the aggregated ratings for the product and a paginated list of reviews. Products, categories, and currencies are managed in the backend and are integrated in the frontend using the Service Bus from T6.4, licenses and their integration in the frontend are currently not available in the live build but are already integrated on a development version. This detail page also shows combinations of license and currencies in which the zApp is available.
Figure 52: License Selection
If the user clicks the “Buy” button, they will be presented with licenses including their durations. This list only includes the licenses which are available for the currently selected currency. After selecting the desired license, the zApp will be added to the cart. If the zApp is not available in the current currency, the buy button is be disabled.
After adding the desired zApps to the cart, the user can use the “Go to checkout” button to initiate the payment process.
The payment process in place currently puts the software items in the shopping cart with the selected license. The next step is gathering or confirming the shipment address as this is necessary for tax accounting.
Figure 53: Shopping Cart
Figure 54: Customer Data Acquisition / Updating
The following step is the choice of the desired payment procedure:
Figure 55: Payment Procedure Selection
Currently, only prepayment can be chosen, as all other functionalities need the setup of a contract with payment providers. All payment options are planned to be integrated using Stripe and will be connected as soon as i4FS signs the respective documents. This includes bank transfer, credit card payments (VISA), PayPal and debit cards (MasterCard). For each of these options, billing information is created.
Figure 56: Purchase Summary
In the final step, the transaction was finished. The purchased licenses are displayed in a result screen. After purchasing the licenses, there is a purchases menu item on the lower left-hand side. It leads to a page displaying all currently confirmed licenses for the user’s account.
Figure 57: Product License User Frontend
The frontend allows user login as soon as an account is available:
Figure 58: User Settings Screen
Additional user settings are language and used currency. Currently, only English and German are supported as languages, and Euro, US Dollar and GBP are supported. These currencies are obtained from the Product License Manager.
The software used for 3rd party ideas and suggestions regarding new/changed zApps is based on an Open-Source software called Fider. The usage is straightforward. Requests can be posted on the site, they can be voted and commented upon, images can be attached, and the user is automatically subscribed to changes or answers via email.
Figure 59: Fider zApp Requesting Application Frontend
Marketplace Payment Workflow and Roadmap
The marketplace workflow has been planned and is implemented in four milestones.
Figure 60: Payment Process Milestone 1
In the first milestone, the process is created without an actual payment provider, enabling the purchase of FREE zApps and TRIAL licenses, although without being able to actually upgrade a trial license to a paid one.
The goal of Milestone 1 is to have a prototype payment workflow that actually manages to put valid licenses for users in the License Manager, and therefore enables the platform to test installing zApps and letting users work with them, to enable the other parties to continue working with a functional prototype.
Figure 60: Payment Process Milestone 1, first shows the User Account area, where a call to the License Manager (not shown in the figure) returns the current licenses of the user (in this case there are no licenses shown). Then the next step shows how a user can add trial products and free products to the shopping cart, has to fill out purchase information in a second step, gets shown a purchase summary screen and then can click on buy now to complete the free purchase. The purchase is automatically successful (as it does not incur a cost) and the License Manager is called so the user gets their licenses assigned. When the licenses manager returns with a success code, a confirmation message is shown (not included in the mock-ups of the figure) and the user can see their licenses in the User Account area.
Figure 61: Payment Process Workflow Milestone 2
Milestone 2 (shown in Figure 61: Payment Process Workflow Milestone 2) enables singular payments via Stripe. Stripe is an intermediate payment provider that supports all major Credit Cards, PayPal, Wire Transfer, and many other payment providers. Singular payments means that lifetime licenses and one-stop payments will be supported in this Milestone, as the initial complexity of providing any kind of real payment is high, due to the initial setup with the third-party provider, the handling of errors necessary and the implementation of an external API. At this point also the contracts between i4FS and Stripe need to be forged, if Stripe does not provide a test API with the means to simulate payments and the project decides that test payments are not adequate at this point.
The workflow in the figure shows a similar workflow to the one in the first figure. It differs from the screen with the payment summary, where actual costs and taxes are implied. Note that in the background the database has to collect the actual earnings that have to be shown to the zApp provider, which includes additional calculations based on terms that are not yet fully specified and which depend on the pricing cut that i4FS is going to take from the providers of the zApp.
In case of a failure with the Stripe payment handling, an error is show in the payment summary screen with the possibility to try again, or to go back to the payment details (which might be the reason that the payment could not be processed). If the payment is successful, a call to the License Manager is made so that the licenses can be added to the relevant user account.
Milestone 3 (payment workflow shown in Figure 62) could in theory enable subscriptions and payments that have to be collected after the actual payment process, for example when upgrading from a trial license. To enable this, additional webhooks have to be provided, that the Stripe API will call or that have to be called by the License Manager or via an email that the License Manager might send to a user when their subscription or their trial license is ending soon. As the resources at the end of the project might become sparse, its planned to first run all subscriptions as not automatically updating payments, but instead as one-time payments that the user has to renew manually. The automatic functionality will only be implemented if the APIs are easy to use and the implementation resources are sufficient to implement this feature.
In the example workflow, this feature is shown in the “3 month later” box. When the webhook is called or when the License Manager asks for additional payments, the Marketplace backend tries to automatically book the cost with the payment token saved for that customer, if this feature is implemented. If this is successful, the subscription or the payment is done, and the customer is informed (via email and notification) that the payment was done. If the automatic handling of the payment cannot be executed or as long as the automatic features are not implemented, the user is instead notified that their license soon will not be active anymore and that the payment cannot be executed automatically, with a link to the marketplace cart to execute the payment once more.
There are countless opportunities for this task to be more time-consuming than expected, which is why this is put in the third milestone. If lifetime payments and singular payments can be done as in Milestone 2, then at least the licenses can be manually triggered again so that the functionality of the licenses and the cashflow can be established. Of course, this last milestone still presents itself as a comfort feature that nobody wants to miss, as customers do not have to revisit their buying decisions if the automatic transfers are working – which is preferable from all views.
After Milestone 3, Milestone 4 deals with communication between different instances of the ZDMP Marketplace.
Figure 62: Payment Process Workflow Milestone 3
Figure 63: Milestone 4: Cross-Store Payments
The fourth and last Milestone envisioned manages the cross-store workflow and was technically developed within T6.5 Inter-platform Interoperability. The ZDMP Marketplace is planned as a federated component that can communicate between different instances of itself. The main use case for this is shown in Figure 63: If a company sets up the whole ZDMP platform on local premises, the Marketplace will not have a working contract with Stripe. To enable buying products, a different workflow forwards the payment object to the global Marketplace instance run by i4FS, manages the payment, and then returns the bought license information not only to the License Manager instance in the i4FS managed Cloud instance of ZDMP, but also to the local License Manager which will in turn enable the local components to use the bought zApp.
After Milestone 4, no more project-critical tasks are planned. Possible features that can be worked on include the full implementation of the Stripe API to make subscription bookings automatically, craft well designed emails (instead of basic ones), and a view where the providers of the zApps can get a listing of the income generated, the payment provider costs, the tax costs and i4FS service costs. Also, the payment towards the zApp providers currently relies on manual transfers by i4FS, which should be adapted in the future. Access to a view with logging and historic information could also be planned for the future.
Product and License Manager
Dashboard
The dashboard contains various widget which displays helpful information. At the top of the dashboard are three counters: One for the products, one for the licenses, and the last for the affiliates. The next widget is a chart that displays the license selling evolution in time and monthly and yearly totals. The map widget displays the spreading across the world of the users that bought the licenses:
Figure 64: Backend Dashboard UI
Products List
This screen contains the product list with some of its information such as ID, name, languages, etc. Each product has a status based on its current situation. The list has some additional buttons which allows the user to export that list in CSV, Excel, and PDF file. Also, it has two other buttons that allow the user to copy to clipboard the list or to print it.
Figure 65: Backend zApp List
The product list can be also retrieved via REST API. The list can be ordered, sorted, and filtered while it is retrieved.
The REQUEST:
http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=1&per_page=1Figure 66: Http call for listing first page of products with 1 product per page
The RESPONSE:
{
"data": [
{
"id": "9602-QJKZ",
"name": "Spindle Monitoring App",
"description": "An Application to monitor an Electrospindle device and detect anomalies that could trigger defect. This an evaluation version of the app that allows users to evaluate the anomaly detection capabilities through CSV files.",
"version": 1.35,
"version_purpose": "Promotion",
"supported_platforms": [
{
"id": 1,
"name": "Android"
},
{
"id": 2,
"name": "iOS"
}
],
"categories": [
{
"id": 2,
"name": "Machine Tools",
"description": null,
"image": null,
"icon": null,
"created_at": "2021-06-14T11:17:43.000000Z"
}
],
"translations": [],
"licenses": [
{
"id": 3,
"product_id": 1,
"license_type_id": 3,
"duration": 1,
"price": "0",
"currency_id": "EUR",
"created_at": "2021-06-14T11:26:32.000000Z"
}
],
"tags": [
[
"Spindle"
],
[
"Monitoring"
],
[
"Machine"
],
[
"Tools"
]
],
"images": [],
"download_url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products/9602-QJKZ/download",
"reviews": {
"total": 1,
"average": "4.00",
"current_user": [
{
"id": 4,
"rating": 4,
"review": "This product helped us detect several issues with our spindles. We managed to improve our manufacturing process and now ship with less defects due to optimized spindles. Additionally, we managed to decrease the production cost and our engineers can now focus on other steps in our process.",
"created_at": "2021-06-17T09:21:42.000000Z"
}
]
}
}
],
"links": {
"first": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=1",
"last": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=9",
"prev": null,
"next": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=2"
},
"meta": {
"current_page": 1,
"from": 1,
"last_page": 9,
"links": [
{
"url": null,
"label": "« Previous",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=1",
"label": "1",
"active": true
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=2",
"label": "2",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=3",
"label": "3",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=4",
"label": "4",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=5",
"label": "5",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=6",
"label": "6",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=7",
"label": "7",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=8",
"label": "8",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=9",
"label": "9",
"active": false
},
{
"url": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products?page=2",
"label": "Next »",
"active": false
}
],
"path": "http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/products",
"per_page": "1",
"to": 1,
"total": 9
}
}Figure 67: JSON listing first page of products with 1 product per page
Add a new product
Adding a new product is a process that can be performed in the following ways: Using the Product Manager UI or using the Product Manager REST API.
Every time a product is created, it receives the “Ready for review” status and an email is sent to designated moderators to check if the product has the right information. While the https://software.zdmp.eu/docs/components/enterprise-tier/application-runtime/ product is reviewed, it gets the status “Reviewing” so it cannot be processed by another reviewer at the same time. After reviewing, the moderator sets the next status, either they will accept and product or they will reject it and send it back to the owner to do the necessary changes. Only the accepted products can be displayed in the Marketplace frontend.
In the UI can be found four tabs, each has a set of fields with a common purpose. The Info tab contains the main product information such: Product id, name, version, purpose, download link etc. The primary language is English, and the main currency is Euro.
Figure 68: Add / Edit Product Backend UI
The Additional Prices tab adds the possibility to add different price based on the currency:
Figure 69: Product Prices UI
The Translations tab adds the possibility to translate the product name and product description. There is no limit, it can be translated to any known language.
Figure 70: Translations UI
The images tab adds the possibility to display screenshots of the product and its functions:
Figure 71: Product Screenshots UI
The product can be created also via REST API:
http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/productsFigure 72: Create product HTTP call
{
"product_id": "123",
"name": "App name",
"description": "App description"
}Figure 73: Product created JSON response
Add a new license
The license list can be seen via the Product and License Manager UI. After each new license, the product owner receives an email notifying him about the purchase.
Figure 74: Product License Creation UI
The license can be created only with the REST API, below can be seen a test request:
http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/licensesFigure 75: License creation Http call
{
"product_id": "123",
"license_type_id": 1,
"duration": 2,
"currency_id": "USD",
"ref_id": "b5c70892ee83add32780ced2e9dc6e0c"
}Figure 76: License created JSON response
CRUD Supported platforms
Each product is created for certain platforms. The product form has a select box with multiple options from which the user can choose the supported platforms. That list is manageable in the Supported Platforms screen where they can be added or edited.
Figure 77: Supported Platforms UI
This list can also be retrieved using the REST API. This is necessary because the user needs the platforms IDs for the product creations request.
http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/platformsFigure 78: List supported platforms Http call
[
{
"id": 1,
"name": "Android"
},
{
"id": 2,
"name": "iOS"
}
]Figure 79: Available platforms JSON response
CRUD License Types
Each license has a type which is required for the notification system and the license management system. These types are manageable in the License Type screen:
Figure 80: License Type Screen
This list can also be retrieved using the REST API. This is necessary because the user needs the license type ids for the license creations request:
http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/licenses/typesFigure 81: Retrieve Licenses type Http call
[
{
"type": 1,
"name": "One time purchase",
"created_at": "2021-06-14T11:17:43.000000Z",
"translations": []
},
{
"type": 2,
"name": "Subscription",
"created_at": "2021-06-14T11:17:43.000000Z",
"translations": []
},
{
"type": 3,
"name": "Test",
"created_at": "2021-06-14T11:17:43.000000Z",
"translations": []
}
]Figure 82: List of the license types JSON response
CRUD Version Purpose
Each product is created for certain purpose. The product form has a select box multiple options from which the user can choose the version purpose. That list is manageable in the Version Purposes screen where they can be added or edited.
Figure 83: Version Purpose Screen
This list can also be retrieved using the REST API. This is necessary because the user needs the version purpose id for the product creation request:
http://product-license-manager-zdmp.platform.zdmp.eu/api/v1/version-purposesFigure 84: retrieve version Http call
[
{
"id": 1,
"name": "Shop"
},
{
"id": 2,
"name": "Website"
},
{
"id": 3,
"name": "Promotion"
}
]Figure 85: List available version JSON response
CRUD Currency List
Each product has at least a price with a currency. This screen allows the user to edit the currency names and symbols at this point.
Figure 86: Currency List UI
Affiliates
Each user can create referral links for tracking the sales of a product in various contexts like social media, backlinks etc:
Figure 87: Affiliate Referral User Interface