Skip to content

K
konnektbox-edgex-go
Commit 98a3f806 authored by Michael Hall's avatar Michael Hall
Browse files
Options

Removes ./docs/ folder which now resides in the edgex-docs repo 

Fixed #1528
Signed-off-by: default avatarMichael Hall <mhall119@gmail.com>
parent f806bb06
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 0 additions and 10281 deletions
docs/Dockerfile.build deleted 100644 → 0
View file @ f806bb06
FROM ubuntu:16.04
MAINTAINER Steve Osselton <steve@iotechsys.com>
# Install software to build docs
RUN apt-get update
RUN apt-get install -y git python-pip latexmk texlive-latex-recommended \
texlive-latex-extra texlive-fonts-recommended nodejs npm make linkchecker
RUN ln -s /usr/bin/nodejs /usr/bin/node
RUN pip install sphinx==1.7.9 sphinxcontrib-googleanalytics==0.1
RUN npm i -g raml2html@3.0.1
RUN mkdir docbuild
WORKDIR /docbuild
# Clone documentation sources in other repositories
#RUN git clone https://github.com/edgexfoundry/support-notifications
RUN git clone https://github.com/edgexfoundry/support-rulesengine
RUN git clone https://github.com/edgexfoundry/device-virtual
# Copy in local documentation sources
COPY export/* ./
COPY export/client/* ./
COPY export/distro/* ./
COPY configuration ./
COPY api ./
COPY core/* ./
COPY core/data/* ./
COPY core/metadata/* ./
COPY core/command/* ./
COPY device/* ./
COPY device/sdk/* ./
COPY device/profile/* ./
COPY device/virtual/* ./
COPY support/* ./
COPY support/scheduler/* ./
COPY support/logging/* ./
COPY support/notifications/* ./
COPY support/rulesengine/* ./
COPY system-management/* ./
COPY examples ./
COPY general ./
COPY getting-started ./
COPY walk-through ./
COPY quick-start ./
COPY security/* ./
COPY application/* ./
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
docs/_config.yml deleted 100644 → 0
View file @ f806bb06
theme: jekyll-theme-slate
\ No newline at end of file
docs/api/Ch-APICoreCommand.rst deleted 100755 → 0
View file @ f806bb06
###################################
APIs - Core Services - Core Command
###################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-Command`
============
Introduction
============
EdgeX Foundry's Command microservice is a conduit for other services to trigger action on devices and sensors through their managing Device Services. 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 into two groups for each device:
* GET commands are issued to a device or sensor to get a current value for a particular attribute on the device, such as the current temperature provided by a thermostat sensor, or the on/off status of a light.
* PUT commands are issued to a device or sensor to change the current state or status of a device or one of its attributes, such as setting the speed in RPMs of a motor, or setting the brightness of a dimmer light.
https://github.com/edgexfoundry/edgex-go/blob/master/api/raml/core-command.raml
.. _`Core Command API HTML Documentation`: core-command.html
..
`Core Command API HTML Documentation`_
docs/api/Ch-APICoreData.rst deleted 100755 → 0
View file @ f806bb06
################################
APIs - Core Services - Core Data
################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-CoreData`
============
Introduction
============
EdgeX Foundry Core Data Service includes the device and sensor collected data database and APIs to expose the database to other services as well as north-bound integration. The database is secure. Direct access to the database is restricted to the Core Data service APIs. Core Data also provides the REST API to create and register a new device.
.. _`Core Data API HTML Documentation`: core-data.html
..
https://github.com/edgexfoundry/edgex-go/blob/master/api/raml/core-data.raml
`Core Data API HTML Documentation`_
docs/api/Ch-APICoreMetadata.rst deleted 100755 → 0
View file @ f806bb06
####################################
APIs - Core Services - Core Metadata
####################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-Metadata`
============
Introduction
============
The Metadata microservice includes the device/sensor metadata database and APIs to expose the database to other services. In particular, the device provisioning service deposits and manages device metadata through this service. This service may also hold and manage other configuration metadata used by other services on the gateway such as clean up schedules, hardware configuration (Wi-Fi connection info, MQTT queues, and so forth). Non-device metadata may need to be held in a different database and/or managed by another service–depending upon implementation.
https://github.com/edgexfoundry/edgex-go/blob/master/api/raml/core-metadata.raml
.. _`Core Metadata API HTML Documentation`: core-metadata.html
..
`Core Metadata API HTML Documentation`_
docs/api/Ch-APICoreServiceConfiguration.rst deleted 100755 → 0
View file @ f806bb06
#################################################
APIs - Core Services - Configuration and Registry
#################################################
======================
Architecture Reference
======================
For a description of the architecture, see see :doc:`../Ch-Configuration`
============
Introduction
============
The RESTful APIs are provided by Consul directly, and several communities supply Consul client libraries for different programming languages, including Go (official), Python, Java, PHP, Scala, Erlang/OTP, Ruby, Node.js, and C#.
For the client libraries of different languages, please refer to the list of this page:
https://www.consul.io/downloads_tools.html
========================
Configuration Management
========================
For the current API documentation, please refer to the official Consul web site:
https://www.consul.io/intro/getting-started/kv.html
https://www.consul.io/docs/agent/http/kv.html
================
Service Registry
================
For the current API documentation, please refer to the official Consul web site:
https://www.consul.io/intro/getting-started/services.html
https://www.consul.io/docs/agent/http/catalog.html
https://www.consul.io/docs/agent/http/agent.html
https://www.consul.io/docs/agent/checks.html
https://www.consul.io/docs/agent/http/health.html
**Service Registration**
While each microservice is starting up, it should connect to Consul to register its endpoint information, including microservice ID, address, port number, and health checking method. After that, other microservices can locate its URL from Consul, and Consul has the ability to monitor its health status. The RESTful API of registration is described on the following Consul page:
https://www.consul.io/docs/agent/http/agent.html#agent_service_register
**Service Deregistration**
Before microservices shut down, they have to deregister themsleves from Consul. The RESTful API of deregistration is described on the following Consul page:
https://www.consul.io/docs/agent/http/agent.html#agent_service_deregister
**Service Discovery**
Service Discovery feature allows client micro services to query the endpoint information of a particular microservice by its microservice IDor list all available services registered in Consul. The RESTful API of querying service by microservice IDis described on the following Consul page:
https://www.consul.io/docs/agent/http/catalog.html#catalog_service
The RESTful API of listing all available services is described on the following Consul page:
https://www.consul.io/docs/agent/http/agent.html#agent_services
**Health Checking**
Health checking is a critical feature that prevents using services that are unhealthy. Consul provides a variety of methods to check the health of services, including Script + Interval, HTTP + Interval, TCP + Interval, Time to Live (TTL), and Docker + Interval. The detailed introduction and examples of each checking methods are described on the following Consul page:
https://www.consul.io/docs/agent/checks.html
The health checks should be established during service registration. Please see the paragraph on this page of Service Registration section.
docs/api/Ch-APIDeviceServicesVirtual.rst deleted 100755 → 0
View file @ f806bb06
###############################################
APIs - Device Services - Virtual Device Service
###############################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-VirtualDevice`
=============
SDK Reference
=============
To use the Software Development Kit (SDK), see :doc:`../Ch-GettingStarted`
============
Introduction
============
The Virtual Device Service simulates different kinds of devices to generate Events and Readings to Core Data Microservice and Users can send commands and get responses through the Command and Control Microservice. The ability to do these activities is very useful when executing functional or performance tests without any real devices. This version of Virtual Device Service is implemented based on the Device Service SDK.
https://github.com/edgexfoundry/device-virtual/blob/master/raml/device-virtual.raml
.. _`Virtual Device API HTML Documentation`: device-virtual.html
..
`Virtual Device API HTML Documentation`_
docs/api/Ch-APIExportClientRegistration-MQTT.rst deleted 100644 → 0
View file @ f806bb06
This diff is collapsed.
docs/api/Ch-APIExportServicesClientRegistration.rst deleted 100755 → 0
View file @ f806bb06
############################################
APIs - Export Services - Client Registration
############################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-ClientRegistration`
============
Introduction
============
EdgeX Foundry Export Client Registration microservice enables clients to register for data from EdgeX Foundry through REST, and specify compression, encryption, format (JSON, XML), and destination of data.
https://github.com/edgexfoundry/edgex-go/blob/master/api/raml/export-client.raml
.. _`Export client API HTML Documentation`: export-client.html
..
`Export client API HTML Documentation`_
========
Examples
========
.. toctree::
:maxdepth: 2
Ch-APIExportClientRegistration-MQTT
Ch-APIExportServicesClientRegistrationExamples
docs/api/Ch-APIReference.rst deleted 100755 → 0
View file @ f806bb06
#############
API Reference
#############
.. toctree::
:maxdepth: 2
Ch-APICoreServiceConfiguration
Ch-APICoreData
Ch-APICoreMetadata
Ch-APICoreCommand
Ch-APISupportingServicesAlerts
Ch-APISupportingServicesLogging
Ch-APISupportingServicesScheduling
Ch-APISupportingServicesRulesEngine
Ch-APIExportServicesClientRegistration
Ch-APIDeviceServicesVirtual
Ch-APISystemManagement
docs/api/Ch-APISupportingServicesAlerts.rst deleted 100755 → 0
View file @ f806bb06
###################################################
APIs - Supporting Services - Alerts & Notifications
###################################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-AlertsNotifications`
============
Introduction
============
When a person or a system needs to be informed of something discovered on the node by another microservice on the node, EdgeX Foundry's Alerts and Notifications microservice delivers that information. Examples of Alerts and Notifications that other services might need to broadcast include sensor data detected outside of certain parameters, usually detected by a Rules Engine service, or a system or service malfunction, usually detected by system management services.
https://github.com/edgexfoundry/support-notifications/blob/master/raml/support-notifications.raml
.. _`Alerts and Notifications API HTML Documentation`: support-notifications.html
..
`Alerts and Notifications API HTML Documentation`_
docs/api/Ch-APISupportingServicesLogging.rst deleted 100755 → 0
View file @ f806bb06
####################################
APIs - Supporting Services - Logging
####################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-Logging`
============
Introduction
============
Logging Service is a microservice featuring REST API for other microservices to add, query, and delete logging requests. Two options of persistence--file or mongodb--are supported and configurable through the property file or remote consul configuration service.
https://github.com/edgexfoundry/edgex-go/blob/master/api/raml/support-logging.raml
.. _`Logging API HTML Documentation`: support-logging.html
..
`Logging API HTML Documentation`_
docs/api/Ch-APISupportingServicesRulesEngine.rst deleted 100755 → 0
View file @ f806bb06
#########################################
APIs - Supporting Services - Rules Engine
#########################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-RulesEngine`
============
Introduction
============
EdgeX Foundry Rules Engine Microservice receives data from the Export Service through 0MQ, and then triggers actuation based on event data it receives and analyzes. Built on Drools technology.
https://github.com/edgexfoundry/support-rulesengine/blob/master/raml/support-rulesengine.raml
.. _`Rules engine API HTML Documentation`: support-rulesengine.html
..
`Rules engine API HTML Documentation`_
docs/api/Ch-APISupportingServicesScheduling.rst deleted 100755 → 0
View file @ f806bb06
#######################################
APIs - Supporting Services - Scheduling
#######################################
======================
Architecture Reference
======================
For a description of the architecture, see :doc:`../Ch-Scheduling`
============
Introduction
============
The following is and example of the EdgeX Foundry Scheduler Service RESTful API.
https://github.com/edgexfoundry/edgex-go/blob/master/api/raml/support-scheduling.raml
.. _`Scheduling API HTML Documentation`: support-scheduler.html
..
`Scheduling API HTML Documentation`_
===========
Description
===========
**Scheduler Service** - a service that can be used to schedule invocation of a URL. Requires the use of interval(s), and interval action(s).
**Interval(s)**
* **name** - unique name of the service.
* **start** - identifies when the operation starts. Expressed in ISO 8601 YYYYMMDD'T'HHmmss format. Empty means now.
* **end** - identifies when the operation ends. Expressed in ISO 8601 YYYYMMDD'T'HHmmss format. Empty means never
* **frequency** - identifies the interval between invocations. Expressed in ISO 8601 PxYxMxDTxHxMxS format. Empty means no frequency.
**Interval Action(s)**
* **name** - unique name of the interval action.
* **interval** - unique name of an existing interval.
* **target** - the recipient of the interval action (ergo service or name).
* **protocol** - the protocol type to be used to contact the target. (example HTTP).
* **httpMethod** - HTTP protocol verb.
* **address** - the endpoint server host.
* **port** - the desired port.
* **path** - the api path which will be acted on.
* **parameters** - (optional) parameters which will be included in the BODY tag for HttpMethods. Any parameters that should be provided to the call, e.g. {"milliseconds":86400000}
========
Examples
========
Create an interval upon which the scheduler will operate
::
curl -X POST -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{
"name": "midnight",
"start": "20180101T000000",
"frequency": "P1D"}' "http://localhost:48081/api/v1/interval"
Example of a second interval which will run every 20 seconds
::
curl -X POST -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{
"name": "every20s",
"start":"20000101T000000",
"end":"",
"frequency":"PT20S"}' "http://localhost:48081/api/v1/interval"
Create an interval action that will invoke the interval action (drive the scrubber) in core-data
::
curl -X POST -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{
"name": "scrub-pushed-events",
"interval": "midnight",
"target": "core-data",
"protocol": "http",
"httpMethod": "DELETE",
"address": "localhost",
"port": 48080,
"path": "/api/v1/event/scrub"}' "http://localhost:48085/api/v1/intervalaction"
This is a Random-Boolean-Device which created by edgex-device-virtual that connects every 20 seconds.
::
curl -X POST -H "Content-Type: application/json" -d '{
"name": "put-action",
"interval": "every20s",
"target": "edgex-device-modbus",
"protocol": "http",
"httpMethod": "PUT",
"address": "localhost",
"port": 49990,
"path":"/api/v1/device/name/Random-Boolean-Device/RandomValue_Bool",
"parameters": "{\"RandomValue_Bool\": \"true\",\"EnableRandomization_Bool\": \"true\"}"
}' "http://localhost:48085/api/v1/intervalaction"
\ No newline at end of file
docs/api/Ch-APISystemManagement.rst deleted 100644 → 0
View file @ f806bb06
################################
APIs - System Management - Agent
################################
======================
Architecture Reference
======================
Coming Soon
============
Introduction
============
The EdgeX System Management Agent (SMA) exposes the EdgeX management service API to 3rd party systems. In other words, the Agent serves as a proxy for system management service API calls into each micro service. In the future, the SMA may also offer the management API in other remote management/control system protocols like LWM2M, OMA DM, etc.
https://github.com/edgexfoundry/edgex-go/blob/master/api/raml/system-agent.raml
.. _`System Management API HTML Documentation`: system-agent.html
..
`System Management API HTML Documentation`_
docs/application/Ch-ApplServices.rst deleted 100644 → 0
View file @ f806bb06
##################################
Application Services Microservices
##################################
.. image:: ApplicationServices.png
Application Services are the means to extract, process/transform and send event/reading data from EdgeX to an endpoint or process of your choice.
Application Services are based on the idea of a "Functions Pipeline". A functions pipeline is a collection of functions that process messages (in this case EdgeX event/reading messages) in the order that you've specified. The first function in a pipeline is a trigger. A trigger begins the functions pipeline execution. A trigger is something like a message landing in a watched message queue.
An SDK is provided (the Applicaiton Functions SDK) to help build Application Services by assembling triggers, pre-existing functions and custom functions of your making into a pipeline.
.. toctree::
:maxdepth: 1
Ch-ApplicationServices
Ch-ApplicationFunctionsSDK
**Note** Application Services will replace Export Services in a future EdgeX release.
docs/application/Ch-ApplicationFunctionsSDK.rst deleted 100644 → 0
View file @ f806bb06
This diff is collapsed.