[00:00] In this lesson, we'll talk about</v> the Tag History Splitter Provider. Now in our earlier videos that talk about the Tag Historian, you already saw how to configure history on a tag. So I can edit a tag, I can go down to it's history settings, I can enable history. And then from here, we can specify which of our historical providers we want to store the data at. Although we do run into a little bit of a problem if you wanted to store into multiple at the same time. So this is actually a common scenario you see, with some of our architectures, specifically the Hub-and-Spoke architecture. So in this architecture here, just as a refresher, you do have spokes, which are sort of these smaller installations. And then you do have this centralized hub here. The idea being that the spokes push data towards the hub. Now in this scenario here, say, we look at this one little spoke over here, say it has its own PLCs, its own ignition installation, but it has it's own clients too, or Perspecitve sessions maybe even right, and it has his own database.

[01:06] So the idea being you can look at trends and history from the PLCs that were collected over here on the spoke. But you also want to push that data up to the central or the hub database here. So really you're trying to store into two different locations. Now by far, the easiest way to do this is to use what's called a Tag History Splitter Provider. So if I were to, I'm going to close this here and I'm going to switch over to a web browser here, and I'm looking at my gateway and not just any gateway I am actually looking at the spoke gateway in this scenario. I have a couple of database connections here. I have the, Sample SQLite Database that comes with Quickstart project, but I'm going to ignore that for this video. And I'm going to focus on DB1 and DB2. Specifically DB1 is a connection that leads to the spoke's database. And DB2 is a connection that leads to the hub's database. Now I have these database connections already configured, but let's take a look at the tag history provider.

[02:04] So I'm going to scroll on down here and under Tags, I'm going to click on History and we do see that we have the Datasource History Provider. So these are the providers that are created automatically when you have a database connection, but we actually want a new provider. So I'm going to click on Create new Historical Tag Provider here. And I'm going to select the Tag History Splitter. So I'll click Next. Let's give this a name. What this provider does is instead of storing records itself, it sends the records to two other providers and then those two other providers handle the storage. So this case here, I can set the first connection to DB1 and the second connection to DB2. And that's really all I need to do. So I'll scroll down here and click the Create New Historical Tag Provider button. Okay, we now have our splitter provider, which means I can switch back over to my designer. I can open up the tag editor again. So I'll double click on Ramp0 and we'll look at those history settings again.

[03:02] You may have to refresh this, if you left your Tag Editor open the whole time. But under the Storage Provider, we now have Splitter as an option. Right. So this point forward, once I click OK here, as value changes on this tag are recorded, it's going to be sent to the splitter. And then the splitter is going to send those value changes to DB1 and the DB2 providers. And that's really all you have to do. Now something gets kind of neat about this. If I were to look at that architecture, that diagram one more time here. It's pretty common that folks want the spokes here to have a sort of light database. They don't want to keep records necessarily for long periods of time. They want to keep some local history but they don't want to record everything forever. That's what the hub's for. They want everything forever to go to the hub. So the way you set that up, it's actually really easy. I'm going to head back to my gateway here, and there's really two things you need to do. First back on the splitter settings, I'll go ahead and edit the splitter provider and you can kind of see from the descriptions here, but the way the splitter really works is it does store to both of these two different connections equally.

[04:11] But when we're trying to query from this provider, so say in the spoke's project, say we have a chart on a window or a view somewhere, and the chart is running a query against the splitter provider looking for data from that Ramp0 tag. By default, it would actually request the records from just the first connection in this case. So are, in this case DB1 or the spoke's own database. But it does tell you that you can actually start messing around with these querying properties down here. So I could opt into this Limit First Connection Query, which basically means, okay, any requests or queries against this provider that look for data outside of the time specified here. So outside of one month, will actually go against the second connection. So what that means for us is that we can actually say, alright, only look for, the last couple months of records in the spoke's database, but anything that goes beyond that, go ahead and reach out to the hub and collect the records from there.

[05:05] And then put those on the screen. Now this will go ahead and basically split up how we do the querying. But if you really wanted to keep that database on the spoke light, there's one more thing you'd need to do. So I'll save this change here, but you'd actually need to go and take a look at the history provider for the spoke, right. So if I edit DB1 here, the splitter is handing off to the DB1 provider here, which means any sort of settings on this provider will still be respected. So I could scroll on down here and I can go down to Data Pruning. And I could basically say, go ahead and delete anything that falls outside of a month or two months or however you want to spin that. So really you can have this be as restrictive as you need to be, but then just don't turn on pruning on the DB2 connection. That way you'll keep everything forever. But that about wraps it up for the Task History Splitter, honestly, it's a very simplistic provider to use. You just create it and point it to two different tag history providers and it'll start to store against both of them.