在上一篇中,使用deviceService將數據發送給了core-data中, 並且可以通過api的方式來查看數據
這一篇中,將把core-data的數據通過數據導出服務(export-distro)或APPService輸出到雲端
export-distro是EdgeX體系中自帶的微服務,只能通過配置的方式過濾和簡單的處理數據(包括加密等操作)
在實際開發中, 我們大多數時間用的還是APPService來想雲端(北向)輸出數據
先來實驗一下數據導出服務,例子中, 使用http方式注冊到export-distro並驗證, MQTT方式只給出注冊參數具體實驗過程,導出服務不是本系列文章的重點
https://www.hangge.com/blog/cache/detail_2341.html 這篇博文中講的更加詳細,
先來准備一個可以接收數據的服務器,這里我們就借用上一篇里面,測試設備時寫的那個http服務
並且我們在host4的服務器中啟動起來(go run main.go)就行
發送請求的url就是 http://host4:1210/bye 先用postman測試一下, 忽略我的localhost
現在可以想EdgeX注冊導出雲端的http服務了
檢查一下export-client 和export-distro 兩個服務是否正常運行,
http://host2:48071/api/v1/registration
{ "name": "隨便起不重復", "addressable": { "name": "隨便起不重復", "protocol": "http", "method": "POST", "address": "host4", "port": 1210, "path": "/bye" }, "format": "JSON", "filter":{ "deviceIdentifiers":["rand-numeric(設備名,就是要導出哪個設備的數據)"] }, "enable": true, "destination": "REST_ENDPOINT" }
忽略我的ip
成功后 我們通過 device---->deviceService ----- > EdgeX 的數據就可以轉發給 host4:1210/bye了
啟動host3的服務
我們單獨拿出來一段格式化一下
{ "id": "1c736295-e443-4075-b47b-de63663eeb56", "device": "rand-numeric", "origin": 1584272171882812485, "readings": [ { "id": "73292196-4922-4968-9e4e-5e304e62ede3", "origin": 1584272171882700374, "device": "rand-numeric", "name": "int", "value": "65" } ] }
readings中的內容,就是上傳的數據
接下來我們通過另一個方式來發送數據
也就是我們開發的重點 ApppService服務
AppService主要是使用 app-functions-sdk-go
我們直接使用官方的demo,就像deviceservice的sdk一樣,在官方提供了許多可以用的例子
git clone https://github.com/edgexfoundry-holding/app-service-examples.git
之后我們進入目錄app-service-examples/app-services
我們會看到很多目錄,只留下http-command-service 和simple-filter-xml-post兩個目錄就可以了
http-command-service是之后反控的內容才能用的到, 目前先放在這里
並且吧simple-filter-xml-post 重命名為simple-filter-json-post
退回到app-service-examples目錄
執行命令 make build
這時候可能會出錯誤報錯信息libzmq沒裝
sudo apt-get install libzmq3-dev
安裝完之后再次編譯還是有錯
這是因為包不匹配的原因早成的, 截止到我在寫這邊博客的時候(2020-03-16)
修改go.mod文件內容替換成下面的版本。我挨着試的, 這已經是能用的最高版本了
require ( github.com/dghubble/sling v1.3.0 github.com/edgexfoundry/app-functions-sdk-go v1.0.1-dev.9 github.com/edgexfoundry/go-mod-core-contracts v0.1.33 )
現在打包正確,
注意 app-functions-sdk-go v1.0.1-dev.9 從9往后的版本, 應用服務添加了安全校驗,
如果你和我一樣使用 docker-compose-fuji-no-secty.yml 啟動的docker容器,那么appservice打包后啟動會報錯
按照dev.9及一下版本打包不會有問題
接下來我們修改代碼,讓接收數據並能導出
編輯 appservices/simple-filter-json-post/main.go
在55行左右
edgexSdk.SetFunctionsPipeline( transforms.NewFilter(deviceNames).FilterByDeviceName, transforms.NewConversion().TransformToXML, transforms.NewHTTPSender("<Your endpoint goes here>", "application/xml", false).HTTPPost, )
TransformToXML ==> TransformToJSON
Your endpoint goes here ==> host4:1210/bye
application/xml ==> application/json
重新打包
之后編輯appservices/simple-filter-json-post/res/configure.toml
service 里面的host改成啟動simple-filter-json-post服務的ip
其他項里面的host改成 EdgeX啟動的服務ip 在我這里就是host2
注意到
transforms.NewFilter(deviceNames).FilterByDeviceName,在這里過濾了deviceName
這個值是從42 行 deviceNames, err := edgexSdk.GetAppSettingStrings("DeviceNames")
所以還要修改 appservices/simple-filter-json-post/res/configure.toml 文件的
之后就可以啟動了
我們通過日志來分析
首先是設備產生數字 看一下時間以16這個數字的數據為例 11:55:55
設備的數據發送給了deviceService 時間11:55:55
通過EdgeX給appService,appservice我沒打印日志,截圖是停掉進程之后接的, 所以忽略最后兩行日志
最后發送給北向的http服務,北向服務的時間我沒打印, 湊合看把, 可以注意一下順序, 是一樣的
但是這里要說明的是, 因為我的是demo, 系統完全沒有負載,也都在局域網里面, 所以才能保證了消息的順序,如果是在生產環境中,
由於進入到EdgeX是由消息隊列來通信的, 所以輸出到北向的數據是不能滿足數據順序的, 這里要稍微注意一下
驗證到這里, 差不多一條線的內容就寫完了, 當然我這里只是一個demo, 在系統開發過程中, 還遇到了一些問題,
比如我們的實際場景是我們對接的不是一個設備, 而是對接了一個系統, 這個系統提供了一個數據庫讓我們定時采集數據,如何解決這個問題,
還有開發中, 其實我們很多時候定義資源,不是一對一的關系, 而是一個命令會對應多個deviceResource的時候, 我們的profile文件要怎么寫
隨着開發遇到的問題, 會在主線文章寫完后, 再做整理
下一篇開始, 我們要考慮如何從北向南,也就是反控是如何實現的