0

Forward data to another historian

The mirror functionality was discontinued and Steve Mason proposed this a "proxy configuration that can forward the data along to another historian."

What is that exactly?  I have a historian onsite that is on the control network and we are going to open a port on the business network to push the history to a in town Canary Historian.  It is not clear how this should be configured.

8 replies

null
    • Real-Time Manager at CSE ICON
    • damon_vinciguerra.1
    • 2 wk ago
    • Reported - view

    I believe you'll want to enable the Proxy feature in Store and Forward: https://helpcenter.canarylabs.com/t/x2yfy1h/how-to-configure-a-proxy-server-version-25

    • todd_schroeder
    • 2 wk ago
    • Reported - view

    looks good.  I want to have the corporate side server use its own identity service.  Is there anything that needs to be done to make that work?

    • Real-Time Manager at CSE ICON
    • damon_vinciguerra.1
    • 2 wk ago
    • Reported - view

    That's an interesting piece. I see no issue with the 2 historians being on different identity services. But the SaF will need to be able to write to both (assuming you use the SaF on the control network historian server and not a standalone proxy server). On the Business network historian you can create an API Key for it. My question is, if you update the API token on the SaF that runs the local historian, will it mess with things. The tool tip on the Identity API Token field in the SaF tile implies that it's only used for remote historians, so maybe not.

    I gotta believe this is very doable.

    • smason
    • 6 days ago
    • Reported - view

    If Tag Security is enabled within Identity, a remote SaF will need to be configured with an API token which would need Write permission to the Historian View. So you could create the API token within the corporate Identity service and configure the remote proxy/SaF service to use that token. Multiple SaF services can use the same token.

    If the proxy/SAF is also remote from the site Identity service, you can still create an internal Canary user and link it to the same API token that was generated within the corporate Identity service.

    • todd_schroeder
    • 5 days ago
    • Reported - view

    So If I am pushing data to a historian via the proxy server method...how is the target machine configured?  What are the data collectors needed?  Is it a receiver?  Does it need Store & Forward to receive data from the Proxy?  I am not seeing this configuration documented.

      • smason
      • 4 days ago
      • Reported - view

       It is all done through SaF. Collectors are only used at the beginning of the data collection trail. Once the data has been handed off to the SaF service, it is responsible for sending the data to the next destination, whether it be an intermediate hop (proxy) or a Historian. In either case, there would be a SaF service on the receiving end to either forward the data along to the next destination or hand it off to a local Historian to be stored. There really isn't anything on the Historian side to be configured except to ensure the SaF endpoint 55291 is open for inbound data streams. If you have Tag Security enabled within Identity on the Historian side, the SaF service on the proxy will need to be configured to use an API token.

      • todd_schroeder
      • 4 days ago
      • Reported - view

       do the tags need to be built on the destination?  and if so, with no collector, where?

      • smason
      • 4 days ago
      • Reported - view

       No, the tags are configured within the Collector at the source. These are then passed to the Collector's local SaF service which is then responsible for transporting it to the next destination, whether that be the the site Historian machine, a proxy server, or both. You have some flexibility as to how you want to transport the data from the Collector to the corporate Historian. If you have line of sight between the Collector and the corporate Historian, you can bypass the proxy altogether. So if you're wanting to send data to the site Historian and the corporate Historian, you can list both destination Historians within the Collector U/I separating destinations with a comma. If the Collector machine does not have line of sight with the corporate Historian, you'll need to go through a proxy.

      The proxy could be its own separate server, or configured on the site Historian - whichever makes sense for you. Anywhere a SaF service exists, it can be configured to act as a proxy to forward data onto the next destination. So if you want the site Historian to act as a proxy, you would configure the SaF service to store the data locally AND forward it on to the corporate Historian. Here is what that proxy config would look like:

      "RouteDestinations": [
          {
            "Destinations": [
              {
                "Endpoint": "localhost",
                "ForceHistorianConnection": false
              },
              {
                "Endpoint": "CorporateHistorian",
                "ForceHistorianConnection": false
              }
            ],
            "RegexMatchKind": "SessionCollectorType",
            "RegexMatchPattern": null
          }
        ]

      In this scenario, the Collector would be configured to only send one stream of data to the site Historian. The SaF service on the site Historian is then responsible for handing it off to the local Historian and forwarding it on to the SaF service on the corporate Historian.

      If you want to spin up a separate machine for the proxy service, you would then need to send two streams of data from the Collector: one to the site Historian and the other to the proxy. This proxy would be configured to forward the data on to the corporate Historian. That config would look like this:
       

      "RouteDestinations": [
          {
            "Destinations": [
              {
                "Endpoint": "CorporateHistorian",
                "ForceHistorianConnection": false
              }
            ],
            "RegexMatchKind": "SessionCollectorType",
            "RegexMatchPattern": null
          }
        ]
      

      This article has a Data Collection Architecture video which may be helpful: https://helpcenter.canarylabs.com/t/60yfy6s/understanding-canary-system-architecture-options-version-25

Content aside

print this pagePrint this page
  • 4 days agoLast active
  • 8Replies
  • 39Views
  • 4 Following