Before we jump directly into connecting to your data, we recommend a little bit of planning and data preparation.
At this point in the process, you should have a defined use case for Yurbi in mind. Not sure what your use case is, check out this article and it may provide some guidance.
Breaking down your use case to the smallest common denominator, you have a group of users that need dashboards/reports from <insert some data source here>.
So the first step in this planning process is to identify your data source.
Yurbi shines best when your data is stored in a database that you control and own.
If that is the case, gather the following information before proceeding:
- Type of database (MS SQL, Oracle, MySQL, PostgreSQL, other ODBC compatible)
- Connection information to the database (servername, instance name, at least a read-only userid and password to the database)
- Knowledge of the database tables and schema where the information your users need are located (this is where your IT team typically involved, but if you don’t have one, our support team can help as well)
Your data may also exist in one or more Microsoft Excel Spreadsheets or CSV files.
If that is the case, you want to make sure the Excel spreadsheet is structured properly for importing into Yurbi:
- Row 1 contains your header labels with no blank columns between headers.
- Below the header row is all your data, with no blank rows in your data.
- The spreadsheet you upload becomes a template for future updates, so all your workbook and worksheet names should be as user-friendly as possible..
- If you have multiple spreadsheets, you may want to combine them all into a single workbook (makes updating data easier in the future).
We have a webinar that walks you through the data prep here, take a watch to see more on setting up your spreadsheet.
Your data may exist in a Cloud app or Software as a Service App.
You can connect Yurbi to any JSON based API endpoint and setup schedules to regularly fetch new data.
Yurbi will translate the nested JSON into database tables, that you can then build an App from, just like the database method mentioned above.
We're in the process of building pre-built connections for many SaaS tools but you can also manually create API connections if you're familiar with how to connect to them (oAuth2, API Key, Basic Auth, etc.).
We'll be updating this page and our help center with more info on the API integration over time. For assistance now, please contact us at [email protected].
There are also 3rd party ODBC drivers from our buddies at CDATA that make it possible and you can explore those options.
Here’s a video overview of the datas ource planning step.
The second step of this phase to understand what types of reports your users are looking for.
As a part of this phase, you will be configuring what we call a Yurbi App. A Yurbi App is a semantic layer, that sets on top of your raw data and translates it into user understandable terms. So building a Yurbi App is part technical, the part where you understand the where the data is, the tables, the schema or connections between the data and part business analyst, where you match that data to the requirements your users need.
If you are connecting to a data source where we have a pre-built Premium App (such as BMC ITSM, ServiceNow, CA Service Desk) then you don’t really need to worry about this step, move on to the next step in this phase.
When you get to the Architect portion of Yurbi you will be translating your raw data into:
Report Types – These are the main use cases of your data or a grouping of common reports. For example, in a help desk system, you have Ticket information, Customer information, Asset Information, maybe Survey information. While many of the same fields in the database may be used in those types of reports, logically, as a business user addresses the data, having data fields organized in the way they think about reporting will make it easier for them to build reports.
So think of report types as folders or logical containers of data fields, organized the way your end-users think.
Report Tree – Within each Report Type is a Report Tree. The report tree contains all the fields that you are allowing your end-users to use in reports. So while there are all sorts of fields in your database, not all are needed for them to report on (for example, no need giving them access to internal IDs or password hashtags). The report tree is like a logical folder structure of fields related to the Report Type. The Ticket Information report type would have a Report Tree containing all the fields they need to report on related to tickets.
A key component of the Report Tree is to include all the data transformation fields your report builders need. Such as converting a birthdate field in the database into a SQL function displaying the age which is more meaningful.
Database View – Once connected to a database, Yurbi will have access to all the tables (and the real views in your database) and for each Report Type you will bring in the tables needed, build the relationships between those tables (the schema), and then build the Report Tree for what data fields users can use to build reports.
While we call it a database view, keep in mind this has nothing to do with actual views you have in your database. Yurbi doesn’t require you to modify your database.
Here’s a video overview of this step:
You don’t need to have it all worked out before you start.
While we recommend doing a little planning, the key with Yurbi as an agile business intelligence tool, it’s an iterative process. You can start small, just build a single report type, bring in one or more connected database tables, and add a few fields into your report tree and start building some reports.
Once you learn more about the process, you can go back into the Architect tab and continue to enhance and refine your Yurbi App. You’ll probably have ideas for different Yurbi Apps for different audiences and all sorts of cool use cases.
OK now that you know where we’re headed and what’s needed, let’s go!