This video is taken from the MITS Discover Admin training course. The full course can be found at learning.mits.com.
Other than perhaps the user management section of the Admin tab, the Hypercubes tab is where you'll likely spend the majority of your time when doing administrative tasks in MITS Discover.
Hypercubes are the heart of MITS Discover. They are the basis for all reports, charts, dashboards, and scorecards. During the build process, MITS Discover extracts data from your ERP, aggregates it, calculates any values it needs to, and stores it all in your hypercubes.
The hypercubes, often shortened to just "cubes", are specific to certain logical concepts of data. The Sales cube covers activity around invoiced sales. The AR cube contains data on accounts receivable data, and so on. If you'd like to know more about the specific modules we offer, go to help.mits.com, our public knowledge base, and search for "module descriptions".
Because not every ERP has the same content, not all of the modules will be available for all ERPs. If you see something you'd like but don't have, contact your MITS Account Manager or Support@mits.com to see if it is possible with your ERP.
The Hypercubes tab is divided into two sections. The top section is the scheduler. This is where build jobs for the hypercubes are managed and where you can check on their build history and health. This part of the page is only visible to users who have permission to manage the schedule.
The bottom section shows all of the cubes the current user has access to, the cube's status, and the build range. All users have access to this part of the page, but only the cubes they have permission to see will be listed here. For example, a Sales Rep may only see the SALES, AR, and INVENTORY cubes, where as an admin will have permission to all cubes, so they will all be listed here. You'll also see additional cubes, sometimes called helper cubes, that are part of another cube. The OPEN.PO.HEADER cube is a helper cube that you cannot access directly when making or modifying reports. Its contents are used to help with the calculations in the other cubes. If a user sees a cube here they cannot access in a report, this might be why.
The status section lets you know if the data is complete in the cube, or it's in some other state such as currently building or in error. Hypercubes that are in error or are currently building will not be available to report on and any reports or dashboards objects based on a building or broken cube will not be available until the hypercube is back to the Data Complete state.
The build range on the cube lets you know the range of the data contained in the cube. It is not, this is important, not an indication of when the hypercube was last built. The data in the cube is usually associated with a date field, such as the invoice date or the ship date. The oldest and newest of the dates that the hypercube is based upon are what sets the build range.
For example in our demo cubes, you can see the build ranges stop in 2016 while the build date (shown in the Status column) indicates these cubes were last updated in 2018. This is because our demo data is from a snapshot provided to us by a customer.
The build range is important to know in case you are looking for data that is either too new for it to have been added to the cube yet, or is older than the oldest date set by the cube's configuration. Keep this in mind when a user comes to you complaining about a transaction not being in the cube. Make sure they aren't looking for something that hasn't been added yet or is too old.
Moving back to the top half of the page, let's discuss the scheduler.
The scheduler is where you will manage when the hypercubes build. For the most part, this is a nightly process, run only once per day. This is for a few reasons. First, running the builds will increase the load on your ERP server and may slow it down for your users while we are extracting the data. Second, there is usually not enough change in the data from hour to hour to make a big difference in the decision making process MITS Discover is intended to help you with. Third, as mentioned earlier, the data in the hypercubes is not available to report on while the cubes are building. This means users are not able to run reports or view dashboards while the cubes are building.
There are other reasons as well, but these are the main reasons to not schedule bild jobs to run during working hours.
The scheduler shows you the name of the build job, the hour, day, and month the cube is scheduled to run, the status from the most recent build, and the available actions. Those are usually Run Job Now, Modify, or Delete.
The build job is a series of tasks that are performed to update a cube. Usually is it an extraction and a build, but there may be additional custom tasks included as well. If you're unsure what a certain build tasks does, MITS Support can help, but it is a rare occasion where there is call for you to edit the tasks.
The build job is often named for the main cube in the build tasks, but it doesn't have to be. It can more descriptive, like "weekend build" or "quarterly purge and rebuild".
The status of the build is a clickable link. Clicking it pops up a menu where you can view the details of that build job, view the build log itself, or see a history of the last 50 jobs that have run.
Clicking the build details breaks down how long each step took. If you are seeing large changes in the time it takes to run a build job, comparing the times in the details between two jobs is a good place to start looking for cause.
The View Build Log option takes you directly to the build log for the most recent run of that build job. For the most part, this will not be useful to you and is mainly used by our Support team to troubleshoot problems.
Looking at the build history however, is a good way to spot trending issues with build jobs. Often issues like build jobs taking longer over time, or always failing on a certain day of the week can be spotted by looking at the history. If a build job always fails on the third Friday of the month, for example, you'll want to find out what else is going on at that time that might be impacting the build. Some examples would be server backups, or scheduled jobs within the ERP itself that lock files and prevent us from reading the data.
If the build job has an error or warning, you see that and access them from here. In this case, it tells there is a warning. Warnings are not usually fatal to the cube, it only means some part of the data may not be available or was skipped during the build. Specifically, this warning is saying that someone tried to make a calculated column with too many arguments. MITS Discover let them build the column, but it will not function. MITS Support can help you with warnings and errors you don’t understand or know how to correct them.
The Modify link gives you access to the build job's settings.
The configuration is where you can set the job name, provide a description, and lock any additional cubes you want unavailable during the build. MITS Discover will automatically lock any cubes used in the build tasks, so there is usually no reason to alter these selections.
The Job Tasks is where the specific steps of the build job are entered. Again, these are usually setup by the MITS team and there is generally no need to come in and alter them. Doing so could break the build job and make the cube unavailable until it is corrected.
Job Scheduling IS something you should feel free to adjust if you feel the need. This determines when the build jobs is scheduled to run. The interface lets you determine the frequency and time the job will run. Let's change this job to run weekly and see how that works.
I'll change the type to Weekly, set the start time to be 10:00PM, and set it to run Sunday through Thursday.
If you're concerned that this build might take too long and spill over into the workday, you can add a stop time. Should the build still be running at that point in time, MITS will issue a stop command to the build. When the build reaches the next step, it will stop the build job. This could take effect right away or it could take minutes or hours, depending on where the build job is in its process. The other thing to know about stopping a build before it is finished, is that depending on where it is in the process, this may break the cube and leave it unusable until the next time the build job is run.
Generally speaking, it is better to let a build job run to completion than to stop it while it is running.
In the Advanced mode, you can select multiple options from the available lists by holding down the Control key while clicking. This would allow you to set a job to run multiple times in a day if you needed it.
Again use caution when taking advantage of this feature. Remember that the cube will not be accessible while the job is running and most cubes will not have enough changes in a few hours to make a significant impact on the data. Also consider how long a cube typically takes to build. If the run time for a job is fours hours, then running it twice during a day will leave it unavailable for eight or more hours.
The Job History link is another way to access the list of the last 50 builds, their outcomes, and their logs.
Returning to the Scheduler, there is one other option under the Modify link to look at, and it is the Disable/Enable Job option. There may be times for the purpose of troubleshooting when you want to stop a job from running but you don't want to delete it from the system. Or you may have some job that you only run a few times a year as a manual process, such as importing budget data. The disable/enable job option lets you turn off a build job, preventing it from running until you re-enable it.
In our demo system, we have the build jobs disabled because we have a static set of data and nothing new to extract from the ERP these cubes are based on. However, if we wanted to enable them, we'd click on this link and that would toggle the build job to an active state, meaning it would run when it gets to the next time it is scheduled to run.
Finally, there is an option to delete a build job if you are sure you're not going to use it again. Like all other deletes in MITS, this is permanent and cannot be undone. Deleting a build job will not change any data in the hypercubes, but it will remove all history and tasks associated with the job. Unless you are sure you won't need it again, we suggest disabling build jobs rather than deleting them.
This has been a tour of the Hypercubes tab in MITS Discover.