MSSQL → Azure Blob
Beforehand
This use case shows how to set up an SQL connector (here with MSSQL), particularly working on SQL queries with some tuning and how to send the resulting CSV files into Azure Blob.
Details regarding the configurations can be located on the North Azure Blob and South MSSQL connectors pages.
This specific scenario is constructed around the depicted fictional network.
South MSSQL
Make sure you have the URL or IP address of the MSSQL server, along with its associated port, and a read-only user.
While a read-only user is not mandatory, it is strongly recommended to prevent the insertion or update of data through a SQL query. South connectors are designed for accessing data, not for creating new entries.
With the proposed schema, the following settings can be set:
- Host:
10.0.0.1
- Port:
1433
- Database:
oibus-test
You can verify the connection by testing the settings using the Test settings
button.
SQL Queries
OIBus provides query variables such as @StartTime
and @EndTime
. However, their usage is not mandatory.
Without variable
In this example, a moving window interval can regularly retrieve the data without the need for such variables, between now and yesterday:
SELECT data_name AS dataName, value, timestamp FROM table
WHERE timestamp > DATEADD(DAY,-1,GETDATE()) AND timestamp < GETDATE()
Ensure that you compare the date with a field of the same date type, such as a DateTime type. Use a cast or convert function to appropriately handle the field or your comparison date.
In this scenario, the datetime fields section can still be employed to parse dates and output them in the appropriate format.
Only the timestamp
is a date time field, and we do not use it as a reference because it is not utilized with @StartTime
or
@EndTime
.
With variables
The @StartTime
variable captures the last maximum instant retrieved from a previous query. By default, for the initial
query, it takes the current time minus one hour. The @EndTime
variable is replaced by the current time.
To prevent overloading the server with a large query, you can divide the [@StartTime
, @EndTime
] interval into
smaller chunks. This can be configured in the History settings section, from the connector settings:
- Max read interval (in seconds): If set to 60 seconds, and the interval is 1 hour, 60 sub-interval queries will be generated.
- Read delay (in milliseconds) between each sub-interval query.
- Overlap (in milliseconds) deduced a number of milliseconds from the
@StartTime
of the interval that will be chunked, expanding the query interval while still allowing the retrieval of data before the last maximum instant retrieved.
Overlap proves beneficial when certain retrieved data exhibit latency and are stored after the query has been executed. In such cases, it allows for a slight extension of the requested interval.
Exercise caution if your query involves aggregation, as it might alter your data by shifting the time origin of the first interval.
SELECT timestamp, message, level FROM logs
WHERE timestamp > @StartTime AND timestamp < @EndTime