feat: update docs for edgex 3.0 update (#152)

* feat: update docs for edgex 3.0 update

Closes: #137
Signed-off-by: Valina Li <[email protected]>

docs_src/automated-checkout-services/application_services.md → docs_src/automated-vending-services/application_services.md

@@ -1,12 +1,12 @@
 
 # Application Services
 
-The **Automated Checkout** reference implementation utilizes two application services that are used to consume event data from the EdgeX framework.
+The **Automated Vending** reference implementation utilizes two application services that are used to consume event data from the EdgeX framework.
 
 ## List of application services
 
 - Controller Board Status – Handles events coming from the controller board device service.
-- Vending – The main business logic for the Automated Checkout application. This service handles events directly from the card reader device service and inference engine as well as coordinates data between each of the microservices.
+- Vending – The main business logic for the Automated Vending application. This service handles events directly from the card reader device service and inference engine as well as coordinates data between each of the microservices.
 
 ## Controller board status application service
 
@@ -118,7 +118,7 @@ If the `door_closed` property is different than what `as-vending` currently beli
 
 ### `POST`: `/resetDoorLock`
 
-The `POST` call will simply reset the Automated Checkout's internal `vendingState`. This API endpoint has no logic to process any input data - it just responds to a simple `POST`.
+The `POST` call will simply reset the Automated Vending's internal `vendingState`. This API endpoint has no logic to process any input data - it just responds to a simple `POST`.
 
 Simple usage example:
 

docs_src/automated-checkout-services/micro_services.md → docs_src/automated-vending-services/micro_services.md

@@ -1,11 +1,11 @@
 # Other Microservices
 
-The Automated Checkout reference implementation utilizes three services that expose REST API endpoints. These three services handle business logic for the Automated Checkout reference implementation, and are somewhat generic in their design patterns, so for the purposes of the reference implementation, we simply refer to them  "microservices".
+The Automated Vending reference implementation utilizes three services that expose REST API endpoints. These three services handle business logic for the Automated Vending reference implementation, and are somewhat generic in their design patterns, so for the purposes of the reference implementation, we simply refer to them  "microservices".
 
 ## List of microservices
 
 - [Authentication](#authentication-service) - Service that takes a card ID number and returns authentication/authorization status for the card number.
-- [Inventory](#inventory-service) - Service that manages changes to the Automated Checkout's inventory, including storing transactions in an audit log.
+- [Inventory](#inventory-service) - Service that manages changes to the Automated Vending's inventory, including storing transactions in an audit log.
 - [Ledger](#ledger-service) - Service that stores customer financial transactions.
 
 ## Authentication service
@@ -16,14 +16,14 @@ The `ms-authentication` microservice is a service that works with EdgeX to expos
 
 This repository contains logic for working within the following schemas:
 
-- _Card/Cards_ - swiping a card is what allows the Automated Checkout automation to proceed with its workflow. A card can be associated with one of 3 roles:
+- _Card/Cards_ - swiping a card is what allows the Automated Vending automation to proceed with its workflow. A card can be associated with one of 3 roles:
   - Consumer - a typical customer; is expected to open the vending machine door, remove an item, close the door and be charged accordingly
   - Stocker - a person that is authorized to re-stock the vending machine with new products
   - Maintainer - a person that is authorized to fix the software/hardware
 - _Account/Accounts_ - represents a bank account to charge. Multiple people can be associated with an account, such as a married couple
 - _Person/People_ - a person can carry multiple cards but is only associated with one account
 
-The [`ds-card-reader`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ds-card-reader) service is responsible for pushing card "swipe" events to the EdgeX framework, which will then feed into the [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) microservice that then performs a REST HTTP API call to this microservice. The response is processed by the [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) microservice and the workflow continues there.
+The [`ds-card-reader`](https://github.com/intel-retail/automated-vending/tree/main/ds-card-reader) service is responsible for pushing card "swipe" events to the EdgeX framework, which will then feed into the [`as-vending`](https://github.com/intel-retail/automated-vending/tree/main/as-vending) microservice that then performs a REST HTTP API call to this microservice. The response is processed by the [`as-vending`](https://github.com/intel-retail/automated-vending/tree/main/as-vending) microservice and the workflow continues there.
 
 ### Authentication service APIs
 
@@ -78,7 +78,7 @@ This repository contains logic for working within the following schemas:
   - `minRestockingLevel` - the minimum allowable number of units of this type to be stored in the vending machine
   - `createdAt` - the date the inventory item was created and catalogued
   - `updatedAt` - the date the inventory item was last updated (either via a transaction or something else)
-  - `isActive` - whether or not the inventory item is "active", which is not currently actively used by the Automated Checkout reference implementation for any specific purposes
+  - `isActive` - whether or not the inventory item is "active", which is not currently actively used by the Automated Vending reference implementation for any specific purposes
 - _Audit Log_ - an audit log entry contains the following attributes:
   - `cardId` - card number
   - `accountId` - account number
@@ -88,7 +88,7 @@ This repository contains logic for working within the following schemas:
   - `createdAt` - the transaction date
   - `auditEntryId` - and a UUID representing the transaction itself uniquely
 
-The `ms-inventory` microservice receives REST API calls from the upstream [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) application service during a typical vending workflow. Typically, an individual will swipe a card, the workflow will start, and the inventory will be manipulated after an individual has removed or added items to the vending machine and an inference has completed. REST API calls to this service are not locked behind any authentication mechanism.
+The `ms-inventory` microservice receives REST API calls from the upstream [`as-vending`](https://github.com/intel-retail/automated-vending/tree/main/as-vending) application service during a typical vending workflow. Typically, an individual will swipe a card, the workflow will start, and the inventory will be manipulated after an individual has removed or added items to the vending machine and an inference has completed. REST API calls to this service are not locked behind any authentication mechanism.
 
 ### Inventory service APIs
 
@@ -351,7 +351,7 @@ If the `{auditEntryId}` parameter does not correspond to an existing audit log e
 
 The `ms-ledger` microservice updates a ledger with the current transaction information (products purchased, quantity, total price, transaction timestamp). Transactions are added to the consumer's account. Transactions also have an `isPaid` attribute to designate which transactions have been paid/unpaid.
 
-This microservice returns the current transaction to the [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) microservice, which then calls the [`ds-controller-board`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ds-controller-board) microservice to display the items purchased and the total price of the transaction on the LCD.
+This microservice returns the current transaction to the [`as-vending`](https://github.com/intel-retail/automated-vending/tree/main/as-vending) microservice, which then calls the [`ds-controller-board`](https://github.com/intel-retail/automated-vending/tree/main/ds-controller-board) microservice to display the items purchased and the total price of the transaction on the LCD.
 
 ### Ledger service APIs
 

docs_src/configuration.md

@@ -1,29 +1,13 @@
 # Configuration
 
-This page lists all of the relevant configuration parameters for each service in the Automated Checkout reference implementation.
+This page lists all of the relevant configuration parameters for each service in the Automated Vending reference implementation.
 
 !!!info
-    Note that this document likely does not cover EdgeX-specific configuration parameters. Application and device service SDK documentation can be found in the [EdgeX Foundry GitHub repositories](https://github.com/edgexfoundry) or in the [official EdgeX documentation here](https://docs.edgexfoundry.org/2.2/).
+    Note that this document likely does not cover EdgeX-specific configuration parameters. Application and device service SDK documentation can be found in the [EdgeX Foundry GitHub repositories](https://github.com/edgexfoundry) or in the [official EdgeX documentation here](https://docs.edgexfoundry.org/3.0/).
 
 ## Environment overrides
 
-The simplest way to change one of the configuration values described below is via the use of environment variable overrides in the docker compose file. The value of each configuration item in a service's configuration can be overridden with an environment variable specific to that item. The name of the environment variable is the path to the item in the configuration tree with underscores separating the nodes. The character case of each node in the environment variable name must match that found in the service's configuration. Here are a few examples for the `DriverConfig` section:
-
-```toml
-[DriverConfig]
-  VID = "65535" # 0xFFFF
-  PID = "53"    # 0x0035
-```
-
-```yaml
-Driver_VID: "256" ** Good **
-Driver_PID: "26"  ** Good **
-
-DRIVER_VID: "256" ** BAD **
-driver_pid: "26"  ** BAD **
-```
-
-These overrides are placed in the target service's environment section of the compose file. Here is an example:
+The simplest way to change one of the service's configuration values described below is via the use of environment variable overrides in the docker compose file. The value of each configuration item in a service's configuration can be overridden with an environment variable specific to that item. The name of the environment variable is the path to the item in the configuration tree with underscores separating the nodes. The enviroment variable name is upper case version of the setting that found in the service's configuration. These overrides are placed in the target service's environment section of the compose file. Here is an example:
 
 ```yaml
   ds-card-reader:
@@ -39,7 +23,7 @@ These overrides are placed in the target service's environment section of the co
 
 ## Card reader device service
 
-The following items can be configured via the `DriverConfig` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ds-card-reader/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `DriverConfig` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/ds-card-reader/res/configuration.yaml) file. All values are strings.
 
 - `DeviceSearchPath` - the bash globstar expression to use when searching for the raw input device, default is `/dev/input/event*`
 - `VID` - the `uint16` value (as a base-10 string) corresponding to the Vendor ID of the USB device (run `lsusb` to list VID and PID values of connected USB devices). For example, if the VID is `ffff` in the output of `lsusb`, it is `"65535"` in the configuration file
@@ -48,7 +32,7 @@ The following items can be configured via the `DriverConfig` section of the serv
 
 ## Controller board device service
 
-The following items can be configured via the `DriverConfig` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ds-controller-board/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `DriverConfig` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/ds-controller-board/res/configuration.yaml) file. All values are strings.
 
 - `DisplayTimeout` - The value in seconds corresponding to the display timeout length before resetting the display to the status display.
 - `LockTimeout` - The value in seconds corresponding to the lock timeout used to automatically lock the door in case no lock command was sent
@@ -58,19 +42,20 @@ The following items can be configured via the `DriverConfig` section of the serv
 
 ## EdgeX MQTT device service
 
-This reference implementation uses the [MQTT Device Service](https://github.com/edgexfoundry/device-mqtt-go) from EdgeX with custom device profiles. These device profiles YAML files are located [here](https://github.com/intel-iot-devkit/automated-checkout/blob/master/res/device-mqtt/profiles/inference-mqtt-device-profile.yml) and are volume mounted into the device service's running Docker container.
+This reference implementation uses the [MQTT Device Service](https://github.com/edgexfoundry/device-mqtt-go) from EdgeX with custom device profiles. These device profiles YAML files are located [here](https://github.com/intel-retail/automated-vending/tree/main/res/device-mqtt/profiles/inference-mqtt-device-profile.yml) and are volume mounted into the device service's running Docker container.
 
-The following items can be configured via `MQTTBrokerInfo` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/res/device-mqtt/configuration.toml) file. All values are strings.
+The following `MQTTBrokerInfo` configuration items can be configured via `device-mqtt.environment` section of the service's [docker-compose.edgex.yml](https://github.com/intel-retail/automated-vending/tree/main/docker-compose.edgex.yml) file.
 
-`MQTTBrokerInfo`
+`MQTTBrokerInfo via device-mqtt.environment`
 
-- `Schema` - Data schema type, aka protocol
-- `Host` - Host name of the response MQTT Broker
-- `Port` - Port number of the response MQTT Broker
-- `Qos` - Quality of service agreement between sender and receiver
-- `KeepAlive` - Keep alive duration for the response MQTT Broker
-- `ClientId` - Client ID for the response MQTT Broker
-- `ResponseTopic` - Subscribe topic for the response MQTT Broker
+- `MQTTBROKERINFO_SCHEMA` - Data schema type, aka protocol
+- `MQTTBROKERINFO_HOST` - Host name of the response MQTT Broker
+- `MQTTBROKERINFO_PORT` - Port number of the response MQTT Broker
+- `MQTTBROKERINFO_QOS` - Quality of service agreement between sender and receiver
+- `MQTTBROKERINFO_KEEPALIVE` - Keep alive duration for the response MQTT Broker
+- `MQTTBROKERINFO_CLIENTID` - Client ID for the response MQTT Broker
+- `MQTTBROKERINFO_INCOMINGTOPIC` - Subscribe topic for incoming data from MQTT Broker
+- `MQTTBROKERINFO_RESPONSETOPIC` - Subscribe topic for the response MQTT Broker
 
 ## CV inference device service
 
@@ -101,7 +86,7 @@ Example:
 
 ## Controller board status application service
 
-The following items can be configured via the `ControllerBoardStatus` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-controller-board-status/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `ControllerBoardStatus` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/as-controller-board-status/res/configuration.yaml) file. All values are strings.
 
 - `AverageTemperatureMeasurementDuration` - The time-duration string (i.e. `-15s`, `-10m`) value of how long to process temperature measurements for calculating an average temperature. This calculation determines how quickly a "temperature threshold exceeded" notification is sent
 - `DeviceName` - The string name of the upstream EdgeX device that will be pushing events & readings to this application service
@@ -112,7 +97,7 @@ The following items can be configured via the `ControllerBoardStatus` section of
 - `NotificationEmailAddresses` - A comma-separated values (CSV) string of emails to send notifications to
 - `NotificationLabels` - A comma-separated values (CSV) string of labels to apply to notifications, which are handled by EdgeX
 - `NotificationReceiver` - The human-readable string name of the person/entity receiving the notification, such as `System Administrator`
-- `NotificationSender` - The human-readable string name of the person/entity sending the notification, such as `Automated Checkout Maintenance Notification`
+- `NotificationSender` - The human-readable string name of the person/entity sending the notification, such as `Automated Vending Maintenance Notification`
 - `NotificationSeverity` - A string tag indicating the severity of the notification, such as `CRITICAL`
 - `NotificationName` - A string that is a short label that may be used as part of a URL to delineate the notification subscription, such as `sys-admin`. The EdgeX official documentation says, _"Effectively a name or key that labels the notification"_.
 - `NotificationSubscriptionMaxRESTRetries` - The integer value that represents the maximum number of times to try creating a subscription in the EdgeX notification service, such as `10`
@@ -124,7 +109,7 @@ The following items can be configured via the `ControllerBoardStatus` section of
 
 ## Vending application service
 
-The following items can be configured via the `ApplicationSettings` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `ApplicationSettings` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/as-vending/res/configuration.yaml) file. All values are strings.
 
 - `AuthenticationEndpoint` - Endpoint for authentication microservice
 - `ControllerBoarddisplayResetCmd` - EdgeX Command service command for Resetting the LCD text
@@ -157,6 +142,6 @@ For this particular microservice, there are no specific configuration options. F
 
 ## Ledger microservice
 
-The following items can be configured via the `[ApplicationSettings]` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ms-ledger/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `[ApplicationSettings]` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/ms-ledger/res/configuration.yaml) file. All values are strings.
 
 - `InventoryEndpoint` - Endpoint that correlates to the Inventory microservice. This is used to query Inventory data used to generate the ledgers.