diff --git a/docs_src/V3TopLevelMigration.md b/docs_src/V3TopLevelMigration.md index 4813ddaeef..2501e9badb 100644 --- a/docs_src/V3TopLevelMigration.md +++ b/docs_src/V3TopLevelMigration.md @@ -55,12 +55,12 @@ The [tool here](https://www.convertsimple.com/convert-toml-to-yaml/) can be used The following are where you can find the configuration migration specifics for individual EdgeX services -- [Core Data](../microservices/core/data/Ch-CoreData/#v3-configuration-migration-guide) -- [Core Metadata](../microservices/core/metadata/Ch-Metadata/#v3-configuration-migration-guide) -- [Core Command](../microservices/core/command/Ch-Command/#v3-configuration-migration-guide) -- [Support Notifications](../microservices/support/notifications/Ch-AlertsNotifications/#v3-configuration-migration-guide) -- [Support Scheduler](../microservices/support/scheduler/Ch-Scheduler/#v3-configuration-migration-guide) -- [Application Services](../microservices/application/V3Migration/#configuration) +- [Core Data](#core-data) +- [Core Metadata](#core-metadata) +- [Core Command](#core-command) +- [Support Notifications](#support-notifications) +- [Support Scheduler](#support-scheduler) +- [Application Services](#application-services) - [Device Services (common)](../microservices/device/V3Migration/#configuration) - [Device MQTT](../microservices/device/V3Migration/#device-mqtt) - [Device ONVIF Camera](../microservices/device/V3Migration/#device-onvif-camera) @@ -115,7 +115,7 @@ The Event/Reading data stored by Core Data is considered transient and of little - Add Event To identify which device service generating the new event, POST endpoint is now changed from `/event/{profileName}/{deviceName}/{sourceName}` to `/event/{serviceName}/{profileName}/{deviceName}/{sourceName}` -See [Core Data API Reference](../api/core/Ch-APICoreData) for complete details. +See [Core Data API Reference](./microservices/core/data/ApiReference.md) for complete details. #### Reading - Added `tags` field in reading. @@ -150,14 +150,14 @@ Most of the data stored by Core Metadata will be recreated when the V3 versions - Removed the boolean field `notify` which is never used - Added the new field `tags` and `properties` -See [Core Metadata API Reference](../api/core/Ch-APICoreMetadata) for complete details. +See [Core Metadata API Reference](./microservices/core/metadata/ApiReference.md) for complete details. ### Core Command #### API Change - Get Command - Updated `ds-pushevent` and `ds-returnevent` to use bool value, `true` or `false`, instead of `yes` or `no` -See [Core Command API Reference](../api/core/Ch-APICoreCommand) for complete details. +See [Core Command API Reference](./microservices/core/command/ApiReference.md) for complete details. ### Support Notifications @@ -167,20 +167,20 @@ Any `Subscriptions` created via the V2 REST API will have to be recreated using #### API Change - Added `authmethod` to support-scheduler actions DTO, which indicates how to authenticate the outbound URL. Use `NONE` when running in non-secure mode and `JWT` when running in secure mode. -See [Support Scheduler API Reference](../api/support/Ch-APISupportScheduler) for complete details. +See [Support Scheduler API Reference](./microservices/support/scheduler/ApiReference.md) for complete details. The statically declared `Interval` and `IntervalAction` will be created automatically. Any `Interval` and/or `IntervalAction` created via the V2 REST API will have to be recreated using the V3 REST API. If you have created a custom configuration with additional statically declared `Interval`s and `IntervalActions` see the [Configuration File](#configuration-file) section under [Customized Configuration](#customized-configuration) below. ### Application Services -Application services use the database only when the [Store and Forward](../microservices/application/AdvancedTopics/#store-and-forward) capability is enabled. If you do not use this capability you can skip this section. This data collection only has data when that data could not be exported. It is recommended not to upgrade to V3 while the Store and Forward data collection is not empty or you are certain the data is no longer needed. You can determine if the Store and Forward data collection is empty by setting the Application Service's log level to `DEBUG` and look for the following message which is logged every `RetryInterval`: +Application services use the database only when the [Store and Forward](./microservices/application/sdk/details/StoreAndForward.md) capability is enabled. If you do not use this capability you can skip this section. This data collection only has data when that data could not be exported. It is recommended not to upgrade to V3 while the Store and Forward data collection is not empty or you are certain the data is no longer needed. You can determine if the Store and Forward data collection is empty by setting the Application Service's log level to `DEBUG` and look for the following message which is logged every `RetryInterval`: !!! example ``` msg=" 0 stored data items found for retrying" ``` !!! note - The `RetryInterval` is in the `app-services` section of [common configuration](../microservices/configuration/CommonConfiguration). Changing it there will apply to all Application Services that have the [Store and Forward](../microservices/application/AdvancedTopics/#store-and-forward) capability enabled. + The `RetryInterval` is in the `app-services` section of [common configuration](../microservices/configuration/CommonConfiguration). Changing it there will apply to all Application Services that have the [Store and Forward](./microservices/application/sdk/details/StoreAndForward.md) capability enabled. ### Clearing Redis Database @@ -207,31 +207,31 @@ This will not work if running EdgeX in running in secure mode since you will not ## Custom Device Service -If you have custom Device Services they will need to be migrated to the V3 version of the Device SDK. See [Device Service V3 Migration Guide](../microservices/device/V3Migration) for complete details. +If you have custom Device Services they will need to be migrated to the V3 version of the Device SDK. See [Device Service V3 Migration Guide](./microservices/device/V3Migration.md) for complete details. ## Custom Device Profile -If you have custom V2 Device Profile(s) for one of the EdgeX Device Services they will need to be migrated to the V3 version of Device Profiles. See [Device Service V3 Migration Guide](../microservices/device/V3Migration#device-profiles) for complete details. +If you have custom V2 Device Profile(s) for one of the EdgeX Device Services they will need to be migrated to the V3 version of Device Profiles. See [Device Service V3 Migration Guide](./microservices/device/V3Migration.md#device-profile) for complete details. ## Custom Pre-Defined Device -If you have custom V2 Pre-Defined Device(s) for one of the EdgeX Device Services they will need to be migrated to the V3 version of Pre-Defined Devices. See [Device Service V3 Migration Guide](../microservices/device/V3Migration/#device-files) for complete details. +If you have custom V2 Pre-Defined Device(s) for one of the EdgeX Device Services they will need to be migrated to the V3 version of Pre-Defined Devices. See [Device Service V3 Migration Guide](./microservices/device/V3Migration.md#device-files) for complete details. ## Custom Applications Service - If you have custom Application Services they will need to be migrated to the V3 version of the App Functions SDK. See [Application Services V3 Migration Guide](../microservices/application/V3Migration) for complete details. + If you have custom Application Services they will need to be migrated to the V3 version of the App Functions SDK. See [Application Services V3 Migration Guide](./microservices/application/V3Migration.md) for complete details. ## Security -If you have an add-on services running in secure mode you will need to use the new names of the environment variables in EdgeX V3. See [Security Services V3 Migration Guide](../security/V3Migration) for more details. +If you have an add-on services running in secure mode you will need to use the new names of the environment variables in EdgeX V3. See [Security Services V3 Migration Guide](./security/V3Migration.md) for more details. ### API Gateway configuration -The API gateway has changed in EdgeX V3. See [Security Services V3 Migration Guide](../security/V3Migration) for more details. +The API gateway has changed in EdgeX V3. See [Security Services V3 Migration Guide](./security/V3Migration.md) for more details. ### Authenticated REST APIs -When security is enable, all V3 EdgeX services REST APIs require a JWT authorization token. See [Security Services V3 Migration Guide](../security/V3Migration) for more details. +When security is enable, all V3 EdgeX services REST APIs require a JWT authorization token. See [Security Services V3 Migration Guide](./security/V3Migration.md) for more details. ## eKuiper diff --git a/docs_src/api/core/Ch-APICoreCommand.md b/docs_src/api/core/Ch-APICoreCommand.md index 5136b22333..844ba7f771 100644 --- a/docs_src/api/core/Ch-APICoreCommand.md +++ b/docs_src/api/core/Ch-APICoreCommand.md @@ -2,7 +2,7 @@ EdgeX Foundry's Command microservice is a conduit for other services to trigger action on devices and sensors through their managing Device -Services. See [Core Command](../../../microservices/core/command/Ch-Command/) for more details about this service. +Services. See [Core Command](../../microservices/core/command/GettingStarted.md) for more details about this service. The service provides an API to get the list of commands that can be issued for all devices or a single device. Commands are divided diff --git a/docs_src/design/adr/0026-Common Configuration.md b/docs_src/design/adr/0026-Common Configuration.md index 6907da101d..e2b61f81ef 100644 --- a/docs_src/design/adr/0026-Common Configuration.md +++ b/docs_src/design/adr/0026-Common Configuration.md @@ -9,7 +9,7 @@ - Revised for Configuration Provider as System of Record when used. ## Referenced Use Case(s) -- [Common Configuration UCR](URL of use case link TBD) +- [Common Configuration UCR] - URL of use case link TBD ## Context This ADR describes the architecture of the new common configuration capability which impacts all services. Requirements for this new capability are described in the above referenced UCR. This is deemed architecturally significant due to the cross-cutting impacts. diff --git a/docs_src/design/adr/013-Device-Service-Events-Message-Bus.md b/docs_src/design/adr/013-Device-Service-Events-Message-Bus.md index 7e9c934e49..2344d9c7c9 100644 --- a/docs_src/design/adr/013-Device-Service-Events-Message-Bus.md +++ b/docs_src/design/adr/013-Device-Service-Events-Message-Bus.md @@ -33,7 +33,7 @@ Currently EdgeX Events are sent from Device Services via HTTP to Core Data, whic > *Note: Though this design is centered on device services, it does have cross cutting impacts with other EdgeX services and modules* -> *Note: This ADR is dependent on the [**Secret Provider for All**](TBD) to provide the secrets for secure Message Bus connections.* +> *Note: This ADR is dependent on the **Secret Provider for All** (Link TBD) to provide the secrets for secure Message Bus connections.* ## Decision @@ -231,14 +231,14 @@ SubscribeTopics="edgex/events/#" ### Secure Connections -As stated earlier, this ADR is dependent on the [**Secret Provider for All**](TBD) ADR to provide a common Secret Provider for all Edgex Services to access their secrets. Once this is available, the MessageBus connection can be secured via the following configurable client authentications modes which follows similar implementation for secure MQTT Export and secure MQTT Trigger used in Application Services. +As stated earlier, this ADR is dependent on the **Secret Provider for All**(Link TBD) ADR to provide a common Secret Provider for all Edgex Services to access their secrets. Once this is available, the MessageBus connection can be secured via the following configurable client authentications modes which follows similar implementation for secure MQTT Export and secure MQTT Trigger used in Application Services. - **none** - No authentication - **usernamepassword** - Username & password authentication. - **clientcert** - Client certificate and key for authentication. - The secrets specified for the above options are pulled from the `Secret Provider` using the configured `SecretPath`. -How the secrets are injected into the `Secret Provider` is out of scope for this ADR and covered in the [**Secret Provider for All**](TBD) ADR. +How the secrets are injected into the `Secret Provider` is out of scope for this ADR and covered in the **Secret Provider for All**( Link TBD) ADR. ## Consequences diff --git a/docs_src/design/adr/security/0029-authentication-e2ee.md b/docs_src/design/adr/security/0029-authentication-e2ee.md index db76cc0611..186d49234f 100644 --- a/docs_src/design/adr/security/0029-authentication-e2ee.md +++ b/docs_src/design/adr/security/0029-authentication-e2ee.md @@ -402,6 +402,6 @@ third-party service integration. - [Microservice Authentication UCR](../../ucr/Microservice-Authentication.md) - [ADR 0015 Encryption between microservices](./0015-in-cluster-tls.md) - [ADR 0020 Delay start services (SPIFFE/SPIRE)](./0020-spiffe.md) -- [ADR 0028 Microservice authentication via tokens](./0028-authentication/) +- [ADR 0028 Microservice authentication via tokens](./0028-authentication.md) - [OpenZiti zero-trust networking fabric](https://openziti.github.io/) - [SPIFFE](https://spiffe.io/) diff --git a/docs_src/getting-started/Ch-GettingStartedHybrid.md b/docs_src/getting-started/Ch-GettingStartedHybrid.md index 776a54fd63..14850428cf 100644 --- a/docs_src/getting-started/Ch-GettingStartedHybrid.md +++ b/docs_src/getting-started/Ch-GettingStartedHybrid.md @@ -94,4 +94,4 @@ http://localhost:59880/api/{{api_version}}/event/count *For this example, you can check that the virtual device service is sending data into Core Data by checking the event count.* !!! Note - If you choose, you can also import the service into GoLand and then code and run the service from GoLand. Follow the instructions in the [Getting Started - Go Developers ](Ch-GettingStartedGoDevelopers#edgex-foundry-in-goland) to learn how to import, build and run a service in GoLand. + If you choose, you can also import the service into GoLand and then code and run the service from GoLand. Follow the instructions in the [Getting Started - Go Developers ](./Ch-GettingStartedGoDevelopers.md#edgex-foundry-in-goland) to learn how to import, build and run a service in GoLand. diff --git a/docs_src/index.md b/docs_src/index.md index 3fe22a791c..365b2c99b6 100644 --- a/docs_src/index.md +++ b/docs_src/index.md @@ -32,7 +32,7 @@ EdgeX Foundry is a vendor-neutral open source project hosted by The Linux Founda
- + Build a Device Service

Build a custom device service to connect to your sensor or device.

@@ -41,7 +41,7 @@ EdgeX Foundry is a vendor-neutral open source project hosted by The Linux Founda
- + Build an Application Service

Build or configure a new application service to get data to the cloud, database, enterprise application or other external system.

diff --git a/docs_src/microservices/application/sdk/api/AppFunctionContextAPI.md b/docs_src/microservices/application/sdk/api/AppFunctionContextAPI.md index b4f16ce0bc..4f4a5facff 100644 --- a/docs_src/microservices/application/sdk/api/AppFunctionContextAPI.md +++ b/docs_src/microservices/application/sdk/api/AppFunctionContextAPI.md @@ -198,7 +198,7 @@ This API will replace placeholders of the form `{context-key-name}` with the val `SecretProvider() interfaces.SecretProvider` -This API returns reference to the SecretProvider instance. See [Secret Provider API](../../../security/Ch-SecretProviderApi/) section for more details. +This API returns reference to the SecretProvider instance. See [Secret Provider API](../../../../security/Ch-SecretProviderApi.md) section for more details. ## Store and Forward @@ -208,7 +208,7 @@ The APIs in this section are related to the Store and Forward capability. See th `SetRetryData(data []byte)` -This method can be used to store data for later retry. This is useful when creating a custom export function that needs to retry on failure. The payload data will be stored for later retry based on `Store and Forward` configuration. When the retry is triggered, the function pipeline will be re-executed starting with the function that called this API. That function will be passed the stored data, so it is important that all transformations occur in functions prior to the export function. The `Context` will also be restored to the state when the function called this API. See [Store and Forward](../AdvancedTopics/#store-and-forward) for more details. +This method can be used to store data for later retry. This is useful when creating a custom export function that needs to retry on failure. The payload data will be stored for later retry based on `Store and Forward` configuration. When the retry is triggered, the function pipeline will be re-executed starting with the function that called this API. That function will be passed the stored data, so it is important that all transformations occur in functions prior to the export function. The `Context` will also be restored to the state when the function called this API. See [Store and Forward](../details/StoreAndForward.md) for more details. !!! note `Store and Forward` must be enabled when calling this API, otherwise the data is ignored. diff --git a/docs_src/microservices/application/sdk/api/ApplicationServiceAPI.md b/docs_src/microservices/application/sdk/api/ApplicationServiceAPI.md index 704811b5f7..d2b359d67e 100644 --- a/docs_src/microservices/application/sdk/api/ApplicationServiceAPI.md +++ b/docs_src/microservices/application/sdk/api/ApplicationServiceAPI.md @@ -84,7 +84,7 @@ This factory function returns an `interfaces.ApplicationService` using the defau This factory function returns an `interfaces.ApplicationService` using the passed in Target Type and initializes the service. The second `bool` return parameter will be `true` if successfully initialized, otherwise it will be `false` when error(s) occurred during initialization. All error(s) are logged so the caller just needs to call `os.Exit(-1)` if `false` is returned. -See the [Target Type](../AdvancedTopics/#target-type) advanced topic for more details. +See the [Target Type](../details/TargetType.md) advanced topic for more details. !!! example "Example - NewAppServiceWithTargetType" ``` go @@ -99,7 +99,7 @@ See the [Target Type](../AdvancedTopics/#target-type) advanced topic for more de ## Custom Configuration APIs -The following `ApplicationService` APIs allow your service to access their custom configuration from the configuration file and/or Configuration Provider. See the [Custom Configuration](../AdvancedTopics/#custom-configuration) advanced topic for more details. +The following `ApplicationService` APIs allow your service to access their custom configuration from the configuration file and/or Configuration Provider. See the [Custom Configuration](../details/CustomConfiguration.md) advanced topic for more details. ### ApplicationSettings @@ -321,7 +321,7 @@ This API sets the default functions pipeline with the specified list of Applicat `AddFunctionsPipelineForTopics(id string, topics []string, transforms ...AppFunction) error` -This API adds a functions pipeline with the specified unique ID and list of functions (transforms) to be executed when the received topic matches one of the specified pipeline topics. See the [Pipeline Per Topic](../AdvancedTopics/#pipeline-per-topic) section for more details. +This API adds a functions pipeline with the specified unique ID and list of functions (transforms) to be executed when the received topic matches one of the specified pipeline topics. See the [Pipeline Per Topic](../details/PipelinesPerTopics.md) section for more details. !!! example "Example - AddFunctionsPipelineForTopics" ```go @@ -402,7 +402,8 @@ This API starts the configured trigger to allow the Functions Pipeline to execut `Stop()` -This API stops the configured trigger so that the functions pipeline no longer executes. The internal webserver continues to accept requests. See [Stopping the Service](../AdvancedTopics/#stopping-the-service) advanced topic for more details +This API stops the configured trigger so that the functions pipeline no longer executes. The internal webserver continues to accept requests. +Application Services will listen for SIGTERM / SIGINT signals from the OS and stop the function pipeline in response. The pipeline can also be exited programmatically by calling sdk.Stop() on the running `ApplicationService` instance. This can be useful for cases where you want to stop a service in response to a runtime condition, e.g. receiving a "poison pill" message through its trigger. !!! example "Example - Stop" @@ -413,13 +414,13 @@ This API stops the configured trigger so that the functions pipeline no longer ## Secrets APIs -The following `ApplicationService` APIs allow your service retrieve and store secrets from/to the service's SecretStore. See the [Secrets](../AdvancedTopics/#secrets) advanced topic for more details about using secrets. +The following `ApplicationService` APIs allow your service retrieve and store secrets from/to the service's SecretStore. See the [Secrets](../details/Secrets.md) advanced topic for more details about using secrets. ### SecretProvider `SecretProvider() interfaces.SecretProvider` -This API returns reference to the SecretProvider instance. See [Secret Provider API](../../../security/Ch-SecretProviderApi/) section for more details. +This API returns reference to the SecretProvider instance. See [Secret Provider API](../../../../security/Ch-SecretProviderApi.md) section for more details. ## Client APIs @@ -495,7 +496,7 @@ This API returns the Device Client. Note if Core Metadata is not specified in th ## Background Publisher APIs -The following `ApplicationService` APIs allow Application Services to have background publishers. See the [Background Publishing](../AdvancedTopics/#background-publishing) advanced topic for more details and example. +The following `ApplicationService` APIs allow Application Services to have background publishers. See the [Background Publishing](../details/BackgroundPublishing.md) advanced topic for more details and example. ### AddBackgroundPublisher *DEPRECATED* @@ -527,7 +528,7 @@ This API is deprecated in favor of `AddCustomRoute()` which has an explicit para `AddCustomRoute(route string, authentication Authentication, handler echo.HandlerFunc, methods ...string) error` -This API adds a custom REST route to the application service's internal webserver. If the route is marked authenticated, it will require an EdgeX JWT when security is enabled. A reference to the ApplicationService is added to the context that is passed to the handler, which can be retrieved using the `AppService` key. See [Custom REST Endpoints](../AdvancedTopics/#custom-rest-endpoints) advanced topic for more details and example. +This API adds a custom REST route to the application service's internal webserver. If the route is marked authenticated, it will require an EdgeX JWT when security is enabled. A reference to the ApplicationService is added to the context that is passed to the handler, which can be retrieved using the `AppService` key. See [Custom REST Endpoints](../details/CustomRestApis.md) advanced topic for more details and example. ### AppContext @@ -557,7 +558,7 @@ This API returns the parsed value for the `Service.RequestTimeout` configuration `RegisterCustomTriggerFactory(name string, factory func(TriggerConfig) (Trigger, error)) error` -This API registers a trigger factory for a custom trigger to be used. See the [Custom Triggers](../Triggers/#custom-triggers) section for more details and example. +This API registers a trigger factory for a custom trigger to be used. See the [Custom Triggers](../../details/Triggers.md#custom-triggers) section for more details and example. ### RegisterCustomStoreFactory diff --git a/docs_src/microservices/application/sdk/api/BuiltInPipelineFunctions.md b/docs_src/microservices/application/sdk/api/BuiltInPipelineFunctions.md index 11fd148225..06c99e4347 100644 --- a/docs_src/microservices/application/sdk/api/BuiltInPipelineFunctions.md +++ b/docs_src/microservices/application/sdk/api/BuiltInPipelineFunctions.md @@ -533,7 +533,7 @@ There is one Tags transform included in the SDK that can be added to your pipeli `ToLineProtocol` - This pipeline function will transform the received `dtos.Metric` to a `Line Protocol` formatted string. See https://docs.influxdata.com/influxdb/v2.0/reference/syntax/line-protocol/ for details on the `Line Protocol` syntax. !!! note - When `ToLineProtocol` is the first function in the functions pipeline, the `TargetType` for the service must be set to `&dtos.Metric{}`. See [Target Type](../AdvancedTopics/#target-type) section for details on setting the service's `TargetType`. The Trigger configuration must also be set so `SubscribeTopics="edgex/telemetry/#"` in order to receive the `dtos.Metric` data from other services. See the new App Service Configurable `metrics-influxdb` [profile](https://github.com/edgexfoundry/app-service-configurable/blob/{{edgexversion}}/res/metrics-influxdb/configuration.yaml) for an example. + When `ToLineProtocol` is the first function in the functions pipeline, the `TargetType` for the service must be set to `&dtos.Metric{}`. See [Target Type](../details/TargetType.md) section for details on setting the service's `TargetType`. The Trigger configuration must also be set so `SubscribeTopics="edgex/telemetry/#"` in order to receive the `dtos.Metric` data from other services. See the new App Service Configurable `metrics-influxdb` [profile](https://github.com/edgexfoundry/app-service-configurable/blob/{{edgexversion}}/res/metrics-influxdb/configuration.yaml) for an example. !!! example ``` go diff --git a/docs_src/microservices/application/services/AppRecordReplay/GettingStarted.md b/docs_src/microservices/application/services/AppRecordReplay/GettingStarted.md index 9036813f03..d2f749ba5f 100644 --- a/docs_src/microservices/application/services/AppRecordReplay/GettingStarted.md +++ b/docs_src/microservices/application/services/AppRecordReplay/GettingStarted.md @@ -31,7 +31,7 @@ This runs, in non-secure mode, all the standard EdgeX services along with the De ## Postman -A sample Postman collection is provided to simplify controlling this service via its REST API. See the [Postman Collection](ApiReference.md#postman-collection) section for more details. +A sample Postman collection is provided to simplify controlling this service via its REST API. See the [Postman Collection](./ApiReference.md#postman-collection) section for more details. ## Debug Logging @@ -47,7 +47,7 @@ For **App Rules Engine** we want to filter for messages showing the events recei ### Start a Recording -Before starting a recording session first review the **Start Recording** POST API in the [API Reference](ApiReference.md) section. Be sure to view both examples. +Before starting a recording session first review the **Start Recording** POST API in the [API Reference](./ApiReference.md) section. Be sure to view both examples. The source device service(s) need to be producing events prior to or shortly after the recording is starting. In this guide, Device Virtual is already producing events. So all that is need is to start the recording session by using the `Start Recording` request from the Postman collection referenced above. Edit the `RecordRequest` to set the `duration` and/or `eventLimit` and optionally any of the filters. The existing example filters can be removed so that all events are recorded. @@ -78,7 +78,7 @@ After above is completed simply press `Send` in Postman to start the recording s ### Check Recording Status -The status of a recording session can be checked while it is running or after is has completed. Review the **Recording Status** GET API in the [API Reference](ApiReference.md) section and use the **Recording Status** request from the Postman collection referenced above. Press `Send` in Postman to get the recording status. +The status of a recording session can be checked while it is running or after is has completed. Review the **Recording Status** GET API in the [API Reference](./ApiReference.md) section and use the **Recording Status** request from the Postman collection referenced above. Press `Send` in Postman to get the recording status. !!! example - "Example Recording Status responses" ```json @@ -100,7 +100,7 @@ The status of a recording session can be checked while it is running or after is ### Cancel Recording -A recording session can be canceled while it is running. Review the **Cancel Recording** DELETE API in the [API Reference](ApiReference.md) section and use the **Cancel Recording** request from the Postman collection referenced above. Press `Send` in Postman to cancel the recording session. +A recording session can be canceled while it is running. Review the **Cancel Recording** DELETE API in the [API Reference](./ApiReference.md) section and use the **Cancel Recording** request from the Postman collection referenced above. Press `Send` in Postman to cancel the recording session. !!! note This API will return a **202 - Accepted** response if the recording can be canceled, otherwise it will return an error such as "***failed to cancel recording: no recording currently running***" @@ -109,7 +109,7 @@ A recording session can be canceled while it is running. Review the **Cancel Rec ### Start Replay -To start a replay session first review the **Start Replay** POST API in the [API Reference](ApiReference.md) section and then use the `Start Replay` request from the Postman collection referenced above. +To start a replay session first review the **Start Replay** POST API in the [API Reference](./ApiReference.md) section and then use the `Start Replay` request from the Postman collection referenced above. Set the `replayRate` to desired value. Value must be greater than zero. Values less than 1 replay slower and values greater than 1 replay faster than originally recorded. Value of 1 replays at the originally recorded rate. @@ -129,7 +129,7 @@ After above is completed simply press `Send` in Postman to start the replay sess ### Check Replay Status -The status of a replay session can be checked while it is running or after is has completed. Review the **Replay Status** GET API in the [API Reference.md](ApiReference) section and use the **Replay Status** request from the Postman collection referenced above. Press `Send` in Postman to get the replay status. +The status of a replay session can be checked while it is running or after is has completed. Review the **Replay Status** GET API in the [API Reference.md](./ApiReference.md) section and use the **Replay Status** request from the Postman collection referenced above. Press `Send` in Postman to get the replay status. !!! note This API will always return a **202 - Accepted** response. If there were issues with the replay, the message field will contain the reason. @@ -177,14 +177,14 @@ The status of a replay session can be checked while it is running or after is ha ### Cancel Replay -A replay session can be canceled while it is running. Review the **Cancel Replay** DELETE API in the [API Reference](ApiReference.md) section and use the **Cancel Replay** request from the Postman collection referenced above. Press `Send` in Postman to cancel the replay session. +A replay session can be canceled while it is running. Review the **Cancel Replay** DELETE API in the [API Reference](./ApiReference.md) section and use the **Cancel Replay** request from the Postman collection referenced above. Press `Send` in Postman to cancel the replay session. !!! note This API will return a **202 - Accepted** response if the replay can be canceled, otherwise it will return an error such as "***failed to cancel replay: no replay currently running***" ## Export a Recorded Session -The current recorded session can be exported so that data can be saved to the file system. Review the **Export** GET API in the [API Reference](ApiReference.md) section and use the **Export Recording** requests from the Postman collection referenced above. +The current recorded session can be exported so that data can be saved to the file system. Review the **Export** GET API in the [API Reference](./ApiReference.md) section and use the **Export Recording** requests from the Postman collection referenced above. This API exports all the events, related devices and device profiles. It has an optional `compression` query parameter. Valid values are `none`, `gzip` and `zlib` . Defaults to `none` if not specified. @@ -201,7 +201,7 @@ This API exports all the events, related devices and device profiles. It has an ## Import a Record Session -This API allows a previously exported recording to be imported back into the service. Review the **Import** POST API in the [API Reference](ApiReference.md) section and use the **Import Recording** requests from the Postman collection referenced above. +This API allows a previously exported recording to be imported back into the service. Review the **Import** POST API in the [API Reference](./ApiReference.md) section and use the **Import Recording** requests from the Postman collection referenced above. This API has the optional `overwrite` query parameter, which specifies to overwrite existing Devices and Device Profiles or not. Defaults to true if not set. diff --git a/docs_src/microservices/application/services/AppServiceConfigurable/details/Profiles.md b/docs_src/microservices/application/services/AppServiceConfigurable/details/Profiles.md index f3428e3daa..c520292ef0 100644 --- a/docs_src/microservices/application/services/AppServiceConfigurable/details/Profiles.md +++ b/docs_src/microservices/application/services/AppServiceConfigurable/details/Profiles.md @@ -15,7 +15,7 @@ The profile name selected is used in the service key (`app-[profile name]`) to m e.g. `AppService-sample` when specifying `sample` as the profile. !!! note - If you need to run multiple instances with the same profile, e.g. `http-export`, but configured differently, you will need to override the service key with a custom name for one or more of the services. This is done with the `-sk/-serviceKey` command-line option or the `EDGEX_SERVICE_KEY` environment variable. See the [Command-line Options](../../../details/CommandLine.md#service-key) and [Environment Overrides](../../../details/EnvironmentVariables#edgexservicekey) sections for more detail. + If you need to run multiple instances with the same profile, e.g. `http-export`, but configured differently, you will need to override the service key with a custom name for one or more of the services. This is done with the `-sk/-serviceKey` command-line option or the `EDGEX_SERVICE_KEY` environment variable. See the [Command-line Options](../../../details/CommandLine.md#service-key) and [Environment Overrides](../../../details/EnvironmentVariables.md#edgex_service_key) sections for more detail. !!! note Functions can be declared in a profile but not used in the pipeline `ExecutionOrder` allowing them to be added to the pipeline `ExecutionOrder` later at runtime if needed. diff --git a/docs_src/microservices/configuration/CommonConfiguration.md b/docs_src/microservices/configuration/CommonConfiguration.md index 27f8e69c8a..593ea35fb0 100644 --- a/docs_src/microservices/configuration/CommonConfiguration.md +++ b/docs_src/microservices/configuration/CommonConfiguration.md @@ -20,8 +20,8 @@ The common configuration is divided into 3 sections: - **All Services**- Configuration that is common to all EdgeX Services See below for details. -- **App Services** - Configuration that is common to just application services. See [App Service Configuration](../../application/GeneralAppServiceConfig) section for more details. -- **Device Services**- Configuration that is common to just devices services. See [Device Service Configuration](../../device/Ch-DeviceServices/#configuration-properties) section for more details. +- **App Services** - Configuration that is common to just application services. See [App Service Configuration](../application/Configuration.md) section for more details. +- **Device Services**- Configuration that is common to just devices services. See [Device Service Configuration](../device/Configuration.md#configuration) section for more details. When the Configuration Provider is used, the common configuration is seeded by the **core-common-config-bootstrapper** service, otherwise the common configuration comes from a file specified by the [`-cc/--commonConfig` command-line option](../CommonCommandLineOptions/#common-config). diff --git a/docs_src/microservices/core/command/Configuration.md b/docs_src/microservices/core/command/Configuration.md index d0025db962..45d60e633d 100644 --- a/docs_src/microservices/core/command/Configuration.md +++ b/docs_src/microservices/core/command/Configuration.md @@ -69,4 +69,4 @@ Below are only the additional settings and sections that are specific to Core Co - Removed `RequireMessageBus` - MessageQueue.External moved to ExternalMQTT -See [Common Configuration Reference](../../configuration/V3MigrationCommonConfig/) for complete details on common configuration changes. \ No newline at end of file +See [Common Configuration Reference](../../configuration/V3MigrationCommonConfig.md) for complete details on common configuration changes. \ No newline at end of file diff --git a/docs_src/microservices/core/command/GettingStarted.md b/docs_src/microservices/core/command/GettingStarted.md index 2f9835eb9b..de6a51fa4b 100644 --- a/docs_src/microservices/core/command/GettingStarted.md +++ b/docs_src/microservices/core/command/GettingStarted.md @@ -307,7 +307,7 @@ The payload is the base64-encoding json struct: ### Configuring for secure MQTT connection In real word, users usually need to provide credentials or certificates to connect to external MQTT broker. -To seed such secrets to Secret Store for Command service, you can follow the instructions from the [Seeding Service Secrets](../../security/SeedingServiceSecrets) document. +To seed such secrets to Secret Store for Command service, you can follow the instructions from the [Seeding Service Secrets](../../../security/SeedingServiceSecrets.md) document. The following example shows how to set up Command service to connect to external MQTT broker with `usernamepassword` authentication. diff --git a/docs_src/microservices/device/Configuration.md b/docs_src/microservices/device/Configuration.md index 7fcfea2f4e..834c0ed30f 100644 --- a/docs_src/microservices/device/Configuration.md +++ b/docs_src/microservices/device/Configuration.md @@ -10,7 +10,7 @@ Please refer to the general [Common Configuration documentation](../configuratio **UpdateLastConnected** is removed in EdgeX 3.0. !!! edgey "Edgex 3.0" - For EdgeX 3.0 the `MessageQueue` configuration has been move to `MessageBus` in [Common Configuration](../../../configuration/CommonConfiguration/#configuration-properties) + For EdgeX 3.0 the `MessageQueue` configuration has been move to `MessageBus` in [Common Configuration](../configuration/CommonConfiguration.md#common-configuration-properties) !!! edgey "EdgeX 3.1" @@ -36,7 +36,7 @@ Please refer to the general [Common Configuration documentation](../configuratio ||`EventsSent` = false |Enable/disable reporting of the built-in **EventsSent** metric| ||`ReadingsSent` = false |Enable/disable reporting of the built-in **ReadingsSent** metric| ||`LastConnected` = false |Enable/disable reporting of the built-in **LastConnected** metric| -||`` = false |Enable/disable reporting of custom device service's custom metric. See [Custom Device Service Metrics](../../getting-started/Ch-GettingStartedSDK-Go/#built-in) for more details.| +||`` = false |Enable/disable reporting of custom device service's custom metric. See [Custom Device Service Metrics](../device/sdk/details/CustomConfiguration.md#device-service-sdk---custom-configuration) for more details.| |Tags|``|List of arbitrary service level tags to included with every metric that is reported. | === "Clients.core-metadata*" |Property|Default Value|Description| @@ -121,17 +121,17 @@ Device services can have custom configuration in one of two ways. See the table MySetting: "My Value" ``` === "Custom Structured Configuration" - For Go Device Services see [Go Custom Structured Configuration](../../../getting-started/Ch-GettingStartedSDK-Go/#custom-structured-configuration) for more details. + For Go Device Services see [Go Custom Structured Configuration](../device/sdk/details/CustomConfiguration.md#go-device-service-sdk---custom-structured-configuration) for more details. - For C Device Service see [C Custom Structured Configuration](../../../getting-started/Ch-GettingStartedSDK-C/#custom-structured-configuration) for more details. + For C Device Service see [C Custom Structured Configuration](../device/sdk/details/CustomConfiguration.md#c-device-service-sdk---custom-structured-configuration) for more details. ## Secrets #### Configuration !!! edgey "Edgex 3.0" - For EdgeX 3.0 the **SecretStore** configuration has been removed from each service's configuration files. It has default values which can be overridden with environment variables. See the [SecretStore Overrides](../CommonEnvironmentVariables/#secretstore-overrides) section for more details. + For EdgeX 3.0 the **SecretStore** configuration has been removed from each service's configuration files. It has default values which can be overridden with environment variables. See the [SecretStore Overrides](../configuration/CommonEnvironmentVariables.md#secretstore-configuration-overrides) section for more details. All instances of Device Services running in secure mode require a `SecretStore` to be created for the service by the Security Services. See [Configuring Add-on Service](../../../security/Ch-Configuring-Add-On-Services) for details on configuring a `SecretStore` to be created for the Device Service. With the use of `Redis Pub/Sub` as the default EdgeX MessageBus all Device Services need the `redisdb` known secret added to their `SecretStore` so they can connect to the Secure EdgeX MessageBus. See the [Secure MessageBus](../../../security/Ch-Secure-MessageBus) documentation for more details. @@ -165,4 +165,4 @@ When running in insecure mode, the secrets are stored and retrieved from the *Wr #### Retrieving Secrets -Device Services retrieve secrets from their `SecretStore` using the SDK API. See [Retrieving Secrets](../../../getting-started/Ch-GettingStartedSDK-Go/#retrieving-secrets) for more details using the Go SDK. +Device Services retrieve secrets from their `SecretStore` using the SDK API. See [Retrieving Secrets](../device/sdk/details/Secrets.md#retrieving-secrets) for more details using the Go SDK. diff --git a/docs_src/microservices/device/V3Migration.md b/docs_src/microservices/device/V3Migration.md index 7b2e1b8ad2..40b0383610 100644 --- a/docs_src/microservices/device/V3Migration.md +++ b/docs_src/microservices/device/V3Migration.md @@ -310,11 +310,11 @@ See [Top Level V3 Migration Guide](../../../V3TopLevelMigration) for details app #### Configuration - Helper scripts have been deprecated in favor of using the REST APIs. -See [here for camera credential management](../supported/device-onvif-camera/Walkthrough/deployment#manage-devices), and see [here for configuring `DiscoverySubnets`](../supported/device-onvif-camera/supplementary-info/auto-discovery#discoverysubnets). +See [here for camera credential management](../device/services/device-onvif-camera/Walkthrough/deployment.md#manage-devices), and see [here for configuring `DiscoverySubnets`](../device/services/device-onvif-camera/supplementary-info/auto-discovery.md#discoverysubnets). #### Device Profile -Some commands have been renamed for clarity. See the latest [Swagger API Documentation](../supported/device-onvif-camera/swagger) for full details. +Some commands have been renamed for clarity. See the latest [Swagger API Documentation](../device/services/device-onvif-camera/swagger.md) for full details. | EdgeX v2 Command Name | EdgeX v3 Command Name | |-------------------------------|-------------------------------| diff --git a/docs_src/microservices/device/sdk/api/GoDeviceSDK/GoDeviceSDKAPI.md b/docs_src/microservices/device/sdk/api/GoDeviceSDK/GoDeviceSDKAPI.md index 08eacc3968..bd2a83e81e 100644 --- a/docs_src/microservices/device/sdk/api/GoDeviceSDK/GoDeviceSDKAPI.md +++ b/docs_src/microservices/device/sdk/api/GoDeviceSDK/GoDeviceSDKAPI.md @@ -214,13 +214,13 @@ This API retrieves the specific DeviceCommand instance from device service's cac `LoadCustomConfig(customConfig service.UpdatableConfig, sectionName string) error` This API attempts to load service's custom configuration. It uses the same command line flags to process the custom config in the same manner - as the standard configuration. Returns an error is custom configuration can not be loaded. See [Custom Structured Configuration](../../../getting-started/Ch-GettingStartedSDK-Go/#custom-structured-configuration) section for more details. + as the standard configuration. Returns an error is custom configuration can not be loaded. See [Custom Structured Configuration](../../details/CustomConfiguration.md#go-device-service-sdk---custom-structured-configuration) section for more details. #### ListenForCustomConfigChanges `ListenForCustomConfigChanges(configToWatch interface{}, sectionName string, changedCallback func(interface{})) error` -This API attempts to start listening for changes to the specified custom configuration section. LoadCustomConfig API must be called before this API. See [Custom Structured Configuration](../../../getting-started/Ch-GettingStartedSDK-Go/#custom-structured-configuration) section for more details. +This API attempts to start listening for changes to the specified custom configuration section. LoadCustomConfig API must be called before this API. See [Custom Structured Configuration](../../details/CustomConfiguration.md#go-device-service-sdk---custom-structured-configuration) section for more details. ### Miscellaneous @@ -280,13 +280,13 @@ This API returns the `LoggingClient` used to log messages. `SecretProvider() interfaces.SecretProvider` -This API returns the SecretProvider used to get/save the service secrets. See [Secret Provider API](../../../../security/Ch-SecretProviderApi/) section for more details. +This API returns the SecretProvider used to get/save the service secrets. See [Secret Provider API](../../../../../security/Ch-SecretProviderApi.md) section for more details. #### MetricsManager `MetricsManager () interfaces.MetricsManager` -This API returns the MetricsManager used to register custom service metrics. See [Service Metrics](../../../general/#service-metrics) for more details +This API returns the MetricsManager used to register custom service metrics. See [Service Metrics](../../details/CustomServiceMetrics.md) for more details #### AsyncValuesChannel diff --git a/docs_src/microservices/device/sdk/details/CustomServiceMetrics.md b/docs_src/microservices/device/sdk/details/CustomServiceMetrics.md index f2b16915bb..d7e2eb70af 100644 --- a/docs_src/microservices/device/sdk/details/CustomServiceMetrics.md +++ b/docs_src/microservices/device/sdk/details/CustomServiceMetrics.md @@ -10,9 +10,9 @@ The following built-in device service metrics are collected by the Device SDK 1. **EventSent** - Number of Events that have been sent from the Device Service 2. **ReadingsSent** - Number of Reading that have been sent from the Device Service -3. **Common Metrics** - Set of service metrics common to all EdgeX Services. See [Common Service Metrics](../../microservices/general/#common-service-metrics) for list of all these metrics. +3. **Common Metrics** - Set of service metrics common to all EdgeX Services. See Common Service Metrics(Link TBD) for list of all these metrics. -See [Device Service Configuration Properties](../../microservices/device/Ch-DeviceServices/#configuration-properties) for detail on configuring device service metrics +See [Device Service Configuration Properties](../../../device/Configuration.md) for detail on configuring device service metrics ### Custom @@ -36,7 +36,7 @@ The following are the steps to collect and report service metrics: 3. Determine if there are any tags to report along with your metric. Not common so `nil` is typically passed for the `tags map[strings]string` parameter in the next step. -4. Register your metric(s) with the MetricsManager from the `sdk`reference. See [Device SDK API](../../microservices/device/sdk/SDK-Go-API/#getmetricsmanager) for more details: +4. Register your metric(s) with the MetricsManager from the `sdk`reference. See [Device SDK API](../../sdk/api/GoDeviceSDK/GoDeviceSDKAPI.md) for more details: - `service.MetricsManager().Register("MyCounterName", myCounter, nil)` @@ -50,7 +50,7 @@ The following are the steps to collect and report service metrics: - `myTimer.UpdateSince(someTimeValue)` - `myHistogram.Update(someIntvalue)` -6. Configure reporting of the service's metrics. See `Writable.Telemetry` configuration details in the [Common Configuration](../../microservices/configuration/CommonConfiguration/) section for more detail. +6. Configure reporting of the service's metrics. See `Writable.Telemetry` configuration details in the [Common Configuration](../../../configuration/CommonConfiguration.md) section for more detail. !!! example "Example - Service Telemetry Configuration" ```yaml diff --git a/docs_src/microservices/device/sdk/details/Secrets.md b/docs_src/microservices/device/sdk/details/Secrets.md index 8ed494f921..9215a5fbcf 100644 --- a/docs_src/microservices/device/sdk/details/Secrets.md +++ b/docs_src/microservices/device/sdk/details/Secrets.md @@ -7,9 +7,9 @@ title: Device Service SDK - Secrets ## Configuration !!! edgey "Edgex 3.0" - For EdgeX 3.0 the **SecretStore** configuration has been removed from each service's configuration files. It has default values which can be overridden with environment variables. See the [SecretStore Overrides](../CommonEnvironmentVariables/#secretstore-overrides) section for more details. + For EdgeX 3.0 the **SecretStore** configuration has been removed from each service's configuration files. It has default values which can be overridden with environment variables. See the [SecretStore Overrides](../../../configuration/CommonEnvironmentVariables.md#secretstore-configuration-overrides) section for more details. -All instances of Device Services running in secure mode require a `SecretStore` to be created for the service by the Security Services. See [Configuring Add-on Service](../../../security/Ch-Configuring-Add-On-Services) for details on configuring a `SecretStore` to be created for the Device Service. With the use of `Redis Pub/Sub` as the default EdgeX MessageBus all Device Services need the `redisdb` known secret added to their `SecretStore` so they can connect to the Secure EdgeX MessageBus. See the [Secure MessageBus](../../../security/Ch-Secure-MessageBus) documentation for more details. +All instances of Device Services running in secure mode require a `SecretStore` to be created for the service by the Security Services. See [Configuring Add-on Service](../../../../security/Ch-Configuring-Add-On-Services.md) for details on configuring a `SecretStore` to be created for the Device Service. With the use of `Redis Pub/Sub` as the default EdgeX MessageBus all Device Services need the `redisdb` known secret added to their `SecretStore` so they can connect to the Secure EdgeX MessageBus. See the [Secure MessageBus](../../../../security/Ch-Secure-MessageBus.md) documentation for more details. Each Device Service also has detailed configuration to enable connection to it's exclusive `SecretStore` @@ -41,4 +41,4 @@ When running in insecure mode, the secrets are stored and retrieved from the *Wr ## Retrieving Secrets -The Go Device SDK provides the `SecretProvider.GetSecret()` API to retrieve the Device Services secrets. See the [Device MQTT Service](https://github.com/edgexfoundry/device-mqtt-go/blob/{{edgexversion}}/internal/driver/config.go#L118) for an example of using the `SecretProvider.GetSecret()` API. Note that this code implements a retry loop allowing time for the secret(s) to be push into the service's `SecretStore` via the /secret endpoint. See [Storing Secrets](../../microservices/device/Ch-DeviceServices/#storing-secrets) section for more details. +The Go Device SDK provides the `SecretProvider.GetSecret()` API to retrieve the Device Services secrets. See the [Device MQTT Service](https://github.com/edgexfoundry/device-mqtt-go/blob/{{edgexversion}}/internal/driver/config.go#L118) for an example of using the `SecretProvider.GetSecret()` API. Note that this code implements a retry loop allowing time for the secret(s) to be push into the service's `SecretStore` via the /secret endpoint. See [Storing Secrets](../details/Secrets.md#storing-secrets) section for more details. diff --git a/docs_src/microservices/device/sdk/devicesdk-getting-started/GettingStartedSDK-Go.md b/docs_src/microservices/device/sdk/devicesdk-getting-started/GettingStartedSDK-Go.md index 734a53541f..d212e189a2 100644 --- a/docs_src/microservices/device/sdk/devicesdk-getting-started/GettingStartedSDK-Go.md +++ b/docs_src/microservices/device/sdk/devicesdk-getting-started/GettingStartedSDK-Go.md @@ -14,7 +14,7 @@ See the [Getting Started - Go Developers](../../../../getting-started/Ch-Getting ## Get the EdgeX Device SDK for Go Follow these steps to create a folder on your file system, -download the [Device SDK](../../microservices/device/sdk/Ch-DeviceSDK), and get the GoLang device service SDK on your system. +download the [Device SDK](../devicesdk-getting-started/GettingStartedSDK-Go.md), and get the GoLang device service SDK on your system. 1. Create a collection of nested folders, `~/edgexfoundry` on your file system. This folder will hold your new Device Service. In Linux, create a directory with a single mkdir command ``` bash @@ -309,7 +309,7 @@ sends to EdgeX: Alternatively the `-cc/--commonConfig` flag can be used to specify a file that contains the common configuration. In addition, when running in hybrid mode the `-d/--dev` flag tells the service that it is running in hybrid mode and to override the `Host` names for dependencies with `localhost`. - See [Command Line Options](../../microservices/configuration/CommonCommandLineOptions/) for more details. + See [Command Line Options](../../../configuration/CommonCommandLineOptions.md) for more details. 3. Using a browser, enter the following URL to see the event/reading diff --git a/docs_src/microservices/device/services/device-mqtt.md b/docs_src/microservices/device/services/device-mqtt.md index d6b4c1ae12..bb13a4834e 100644 --- a/docs_src/microservices/device/services/device-mqtt.md +++ b/docs_src/microservices/device/services/device-mqtt.md @@ -4,5 +4,5 @@ Device service for connecting a MQTT enabled devices to EdgeX. See [README](https://github.com/edgexfoundry/device-mqtt-go/tree/{{edgexversion}}#readme) for more details -Also see [Adding MQTT Device Tutorial](../../../../examples/Ch-ExamplesAddingMQTTDevice) for +Also see [Adding MQTT Device Tutorial](../services/device-mqtt/Ch-ExamplesAddingMQTTDevice.md) for more details on using Device MQTT. \ No newline at end of file diff --git a/docs_src/microservices/device/services/device-onvif-camera/Walkthrough/custom-build.md b/docs_src/microservices/device/services/device-onvif-camera/Walkthrough/custom-build.md index cd61653c77..30971c968a 100644 --- a/docs_src/microservices/device/services/device-onvif-camera/Walkthrough/custom-build.md +++ b/docs_src/microservices/device/services/device-onvif-camera/Walkthrough/custom-build.md @@ -139,7 +139,7 @@ Here is some information on how to specially configure parts of the service beyo ### Configure the Device Profiles -The device profile contains general information about the camera and includes all of the device resources and commands that the device resources can use to manage the cameras. The default profile found at `cmd/res/devices/camera.yaml` contains all possible resources a camera could implement. Enable and disable supported resources in this file, or create an entirely new profile. It is important to set up the device profile to match the capabilities of the camera. Information on the resources supported by specific cameras can be found [here](../supplementary-info/ONVIF-protocol.md#tested-onvif-cameras). Learn more about device profiles in EdgeX [here.](../../../../profile/Ch-DeviceProfile) +The device profile contains general information about the camera and includes all of the device resources and commands that the device resources can use to manage the cameras. The default profile found at `cmd/res/devices/camera.yaml` contains all possible resources a camera could implement. Enable and disable supported resources in this file, or create an entirely new profile. It is important to set up the device profile to match the capabilities of the camera. Information on the resources supported by specific cameras can be found [here](../supplementary-info/ONVIF-protocol.md#tested-onvif-cameras). Learn more about device profiles in EdgeX [here.](../../../../core/metadata/details/DeviceProfile.md) !!! example - "Sample: Snippet from camera.yaml" ```yaml diff --git a/docs_src/microservices/device/services/device-onvif-camera/supplementary-info/test-with-postman.md b/docs_src/microservices/device/services/device-onvif-camera/supplementary-info/test-with-postman.md index 5e311d80f2..0f8eb13fc3 100644 --- a/docs_src/microservices/device/services/device-onvif-camera/supplementary-info/test-with-postman.md +++ b/docs_src/microservices/device/services/device-onvif-camera/supplementary-info/test-with-postman.md @@ -98,6 +98,6 @@ Then we can execute other ONVIF function via Postman REST client tool. ## Test device-onvif-camera API -After adding the device according to the [Getting Started Guide](../deployment), then we can import the following Postman collections for testing the APIs: +After adding the device according to the [Getting Started Guide](./getting-started-with-docker-security.md), then we can import the following Postman collections for testing the APIs: - [onvif_camera_with_edgex_postman_collection.json](https://github.com/raw/edgexfoundry/device-onvif-camera/{{edgexversion}}/doc/postman/onvif_camera_with_edgex_postman_collection.json) - [onvif_camera_with_edgex_postman_environment.json](https://github.com/raw/edgexfoundry/device-onvif-camera/{{edgexversion}}/doc/postman/onvif_camera_with_edgex_postman_environment.json) diff --git a/docs_src/microservices/general/index.md b/docs_src/microservices/general/index.md index 9312278abd..8d36b4fd8a 100644 --- a/docs_src/microservices/general/index.md +++ b/docs_src/microservices/general/index.md @@ -33,12 +33,12 @@ If the Event already has `Tags` when it arrives at the application service, then All services have the ability to collect [Common Service Metrics](#common-service-metrics), only **Core Data**, **Application Services** and **Device Services** are collecting additional service specific metrics. Additional service metrics will be added to all services in future releases. See `Writable.Telemetry` at [Common Configuration](../configuration/CommonConfiguration/#configuration-properties) for details on configuring the reporting of service metrics. -See [Custom Application Service Metrics](../application/AdvancedTopics/#custom-application-service-metrics) for more detail on Application Services capability to collect their own custom service metrics via use of the App SDK API. +See [Custom Application Service Metrics](../application/sdk/details/CustomServiceMetrics.md) for more detail on Application Services capability to collect their own custom service metrics via use of the App SDK API. -See [Custom Device Service Metrics](../device/sdk/Ch-DeviceSDK/#custom-device-service-metrics) for more detail on Go Device Services capability to collect their own custom service metrics via use of the Go Device SDK API. +See [Custom Device Service Metrics](../device/sdk/details/CustomServiceMetrics.md) for more detail on Go Device Services capability to collect their own custom service metrics via use of the Go Device SDK API. Each service defines (in code) a set of service metrics that it collects and optionally reports if configured. -The names the service gives to its metrics are used in the service's `Telemetry` configuration to enable/disable the reporting of those metrics. See Core Data's `Writable.Telemetry` at [Core Data Configuration](../core/data/Ch-CoreData/#configuration-properties) as example of the names used for the service metrics that Core Data is currently collecting. +The names the service gives to its metrics are used in the service's `Telemetry` configuration to enable/disable the reporting of those metrics. See Core Data's `Writable.Telemetry` at [Core Data Configuration](../core/data/Configuration.md#core-data---configuration) as example of the names used for the service metrics that Core Data is currently collecting. The following metric types are available to be used by the EdgeX services: @@ -51,7 +51,7 @@ The following metric types are available to be used by the EdgeX services: Service metrics which are enabled for reporting are published to the EdgeX MessageBug every configured interval using the configured `Telemetry` base topic. See `Writable.Telemetry` at [Common Configuration](../configuration/CommonConfiguration/#configuration-properties) for details on these configuration items. The `service name` and the `metric name` are added to the configured base topic. This allows subscribers to subscribe only for specific metrics or metrics from specific services. Each metric is published (reported) independently using the Metric DTO (Data Transfer Object) define in [go-mod-core-contracts](https://github.com/edgexfoundry/go-mod-core-contracts/blob/{{edgexversion}}/dtos/metric.go#L27). The aggregation of these service metrics is left to adopters to implement as best suits their deployment(s). -This can be accomplished with a custom application service that sets the function pipeline `Target Type` to the `dtos.Metric` type. Then create a custom pipeline function which aggregates the metrics and provides them to the telemetry dashboard service of choice via push (export) or pull (custom GET endpoint). See [App Services](../application/AdvancedTopics/#target-type) here for more details on `Target Type`. +This can be accomplished with a custom application service that sets the function pipeline `Target Type` to the `dtos.Metric` type. Then create a custom pipeline function which aggregates the metrics and provides them to the telemetry dashboard service of choice via push (export) or pull (custom GET endpoint). See [App Services](../application/details/Triggers.md) here for more details on `Target Type`. !!! example "Example - DTO from Core Data in JSON format for the `EventsPersisted` metric as publish to the EdgeX MessageBus" ```json diff --git a/docs_src/microservices/general/messagebus.md b/docs_src/microservices/general/messagebus.md index 4d854cff15..e1aae31c15 100644 --- a/docs_src/microservices/general/messagebus.md +++ b/docs_src/microservices/general/messagebus.md @@ -14,11 +14,11 @@ The EdgeX services intended as external entry points are: - **REST API on all the EdgeX services** - Accessed directly in non-secure mode or via the [API Gateway](../../../security/Ch-APIGateway) when running in secure mode -- **App Service using External MQTT Trigger** - An App Service configured to use the [External MQTT Trigger](../../application/Triggers/#external-mqtt-trigger) will accept data from external services on an "external" MQTT connection +- **App Service using External MQTT Trigger** - An App Service configured to use the [External MQTT Trigger](../application/details/Triggers.md#external-mqtt-trigger) will accept data from external services on an "external" MQTT connection -- **App Service using HTTP Trigger** - An App Service configured to use the [HTTP Trigger](../../application/Triggers/#http-trigger) will accept data from external services on an "external" REST connection. Accessed in the same manner as other EdgeX REST APIs. +- **App Service using HTTP Trigger** - An App Service configured to use the [HTTP Trigger](../application/details/Triggers.md#http-trigger) will accept data from external services on an "external" REST connection. Accessed in the same manner as other EdgeX REST APIs. -- **App Service using Custom Trigger** - An App Service configured to use a [Custom Trigger](../../application/Triggers/#custom-trigger) can accept data from external services or over additional protocols with few limitations. See [Custom Trigger Example](https://github.com/edgexfoundry/edgex-examples/tree/{{edgexversion}}/application-services/custom/custom-trigger) for an example. +- **App Service using Custom Trigger** - An App Service configured to use a [Custom Trigger](../application/details/Triggers.md#custom-triggers) can accept data from external services or over additional protocols with few limitations. See [Custom Trigger Example](https://github.com/edgexfoundry/edgex-examples/tree/{{edgexversion}}/application-services/custom/custom-trigger) for an example. - **Core Command External MQTT Connection** - Core Command now receives command requests and publishes responses via an external MQTT connection that is separate from the EdgeX MessageBus. The requests are forwarded to the EdgeX MessageBus and the corresponding responses are forwarded back to the external MQTT connection. @@ -26,7 +26,7 @@ Originally, the EdgeX MessageBus was only used to send *Event/Readings* from Cor - Device Services publish *Event/Readings* directly to the EdgeX MessageBus rather than sending them via REST to Core Data. - [Service Metrics](../#service-metrics) are published to the EdgeX MessageBus -- [System Events](../../core/metadata/Ch-Metadata/#device-system-events) are published to the EdgeX MessageBus. +- [System Events](../core/metadata/details/DeviceSystemEvents.md) are published to the EdgeX MessageBus. - [Command Request/Reponses](../../../design/adr/0023-North-South-Messaging) are now published to the EdgeX MessageBus by Core Command and Devices Services. - Device validation requests from Core Metadata to Device Services via the EdgeX MessageBus. diff --git a/docs_src/walk-through/Ch-WalkthroughReading.md b/docs_src/walk-through/Ch-WalkthroughReading.md index b3139a1dae..037f37919d 100644 --- a/docs_src/walk-through/Ch-WalkthroughReading.md +++ b/docs_src/walk-through/Ch-WalkthroughReading.md @@ -7,7 +7,7 @@ were the camera's device and device service. That is, you will report human and ## Send an Event/Reading -See [core data API](../../api/core/Ch-APICoreData) for more details. +See [core data API](../microservices/core/data/ApiReference.md) for more details. Data is submitted to core data as an `Event` object. An event is a collection of sensor readings from a device (associated to a device by its name) @@ -131,7 +131,7 @@ Use either the Postman or Curl tab below to walkthrough getting the list of even curl -X GET localhost:59880/api/{{api_version}}/reading/device/name/countcamera1 | json_pp ``` -There are [many additional APIs on core data](../../api/core/Ch-APICoreData) to retrieve `Event` and `Reading` data. As an example, here is one to find all events inside of a start and end time range. +There are [many additional APIs on core data](../microservices/core/data/ApiReference.md) to retrieve `Event` and `Reading` data. As an example, here is one to find all events inside of a start and end time range. ``` shel curl -X GET localhost:59880/api/{{api_version}}/event/start/1602168089665560000/end/1602168089665570000 | json_pp diff --git a/mkdocs.yml b/mkdocs.yml index 3a5254ffdd..7b705f699f 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -429,9 +429,14 @@ plugins: enabled: !ENV [ENABLED_HTMLPROOFER, false] raise_error: true raise_error_excludes: + 400: ['https://help.axis.com/en-us/axis-os-hardening-guide#onvif-replay-attack-protection'] + 403: ['https://www.collinsdictionary.com/us/dictionary/english/unit-of-measurement', + 'https://www.pcmag.com/encyclopedia/term/run-native','https://www.vmware.com/topics/glossary/content/kubernetes-cluster.html', + 'https://app.getpostman.com/','https://www.raspberrypi.com/products/raspberry-pi-3-model-b/', + 'https://www.raspberrypi.com/software/'] 404: ['https://support.google.com/accounts/answer/185833?hl=en', 'https://support.google.com/accounts/answer/6010255?hl=en'] 429: ['*'] -1: ['https://www.rfc-editor.org/rfc/rfc7519', - 'https://tools.ietf.org/html/rfc5869','https://docs.iotaap.io/docs-rest/'] + 'https://tools.ietf.org/html/rfc5869','https://docs.iotaap.io/docs-rest/','https://unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_rev3_Annex2e.pdf'] 500: [https://packages.ubuntu.com/bionic/build-essential]