Microstrategy - Dashboards and Documents - document

In Microstrategy 9.4.1 i created a dashboard from the web and then i tryed to edit it from the desktop and i got the following message
this analysis will be converted to a document and the change cannot be undone. are you sure?
I could read on the MSTR site that the difference between Dashboards and Documents is the following:
Document is a editing and formatting of report in a prescribed manner. where as Dashboard is a output result of Document. Dashboard is a Graphical view of Report in Flash mode and it is more interactive.
I want to say also that Documents and Dashboard are two different kind of object, they also have two different icons.
Why while editing a Document from the desktop suite i have more option than from the web?
Can I Edit a Dashboard from the desktop suite? If not, why?

Quite long, go to the end for the quick answers.
Probably there is a bit of confusion on the MicroStrategy documentation because of the history of the terms Documents and Dashboard and how they were used.
In the past, MicroStrategy had only Reports (also called Datasets when used to provide data for a Document or a Dashboard) and Documents.
A MicroStrategy Documents allowed to do more fancy stuff, use data from multiple Reports (or Datasets), more formatting options (headers and footers), show more graphs or grids on the same screen, use Autotext fields (like to automatically show the current date, the prompt answers used, the name of the user running the document), and other thing that I forget now, but I think you got the idea.
Documents could be used to generate those huge PDF reports that nobody was going to read. Then the Business Intelligence world went frenzy for the dashboard thing.
MicroStrategy Documents were perfect for that, you just needed to have the whole document in a single screen and you had a perfect dashboard done with MicroStrategy.
Of course we are talking now about the time when people started to look at their data without printing them, maybe publishing them on the company intranet or some primitive websites.
MicroStrategy embraced this internet revolution offering the possibility to create flash based Documents and the possibility to edit them directly in your browser. I do suspect that at this point MicroStrategy Desktop and the Web editor were quite aligned in terms of functionality (even if sometimes it was hard to find that specific thing: i.e. if you have to format a graph in web you can do it only in the editable mode?)
Release after release the two environments become two different beasts and now some options are available only in one of them (i.e. sorting selector values). Sometimes it seems to me they lost part of the source code of MicroStrategy Desktop so they can do new things only in web. I'm joking :)
Back to dashboards, some of them were nice, most of them were so so (and people started to write about how to show your data in a better way). The main problem is that they are very nice to show data to big bosses, but they have really little value for operation people.
To tackle this problem new tools started to show up, tools to do easily data discovery, data visualization, data analysis, you name it. There were a number of new companies (QliK, Tableau) with new solutions. Initially they were doing just a slice of what a big BI tool was doing but people could use them knowing little or nothing of SQL, Data Warehousing and ETL and they were also looking cool too.
After a while MicroStrategy realized that they needed a cool tool to do the same things if they didn't want to fall behind, so with version 9.2 MicroStrategy announced his own tool for data analysis: MicroStrategy Visual Insight.
MicroStrategy Visual Insight was included with the standard user licenses, had a flash based engine and it was working only on web (and mobile).
Finally in version 9.4 MicroStrategy renamed Visual Insight MicroStrategy Dashboard.
TL;DR:
It's true often you can do a thing in desktop, but you can't do it in MicroStrategy web, or vice versa. Unfortunately nobody knows why.
MicroStrategy Dashboards can be edited only in web because they are flash based.

Related

Excel Mobile Data Entry Form

I am trying to create a data entry "app" to collect daily readings across our site. Here are the three biggest constraints:
Software - ideally, we would use some software within the Microsoft 365 Suite, mainly because those are the only approved apps on site. It may be possible to use open source software, but that might raise some flags in terms of security. So my thoughts are to use either Excel or Access.
Cost - ideally, we do not want purchase any additional software licenses. I would try and create something with Power Apps, but we do not have the licensing for an Azure or SQL server to store the data. I could be missing something here though.
Mobile-Friendly - finally, it needs to work on an Android tablet. Currently, we collect readings using pen and paper. The whole idea of this is to move towards using a tablet.
The easiest approach would be to create an Excel spreadsheet, save it on OneDrive, and edit the spreadsheet. I don't love this option because we are collecting 100's of data points each day. This would end up with a very wide spreadsheet that will be cumbersome to navigate.
The other option I looked into was creating an Access database and accompanying form and storing it on SharePoint. However, it seems Microsoft has stopped supporting Access databases on SharePoint.
I have created data entry forms using VBA, similar to this, but these do not work on mobile.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
I am engaged in just this kind of project also. I have written an app in PowerApps, built an Excel spreadsheet and stored it in OneDrive, and am running it (the app) on an iPad. The design differs somewhat from your description of directly presenting a spreadsheet to the user (which I think PowerApps could do) because I don't want users having direct access to the data.
Edit: You do not need Azure or SQL, unless you are storing tons of data. Excel can be a satisfactory data storage location for modest uses.
I found the learning curve for PowerApps to be quite steep, as it's a different paradigm than line-by-line coding.
I think this is a more user friendly way to collect data than trying to run an Excel form, and once you get it made and polished, you'll look like a pro :)
I am by no means an expert but if you need some tips I'll do what I can to help. It sounds like we are at similar developmental stages.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
Microsoft Forms does the job when created from OneDrive on mobile browser. Side note: the form I just created and the response I submitted have now disappeared from my OneDrive.
I also saw some people using Power Automate to save responses from a form into an Excel file (every reponse).

Using SSRS instead of Crystal reports to generate admin forms

I'm looking into upgrading a .net 2.0 app. The app is used by the public authorities of a certain city to keep track of expenses and generate reports and forms.
The reports and forms were generated in VS2005 using Crystal report. They follow a well defined layout, like official documents usually do.
I am looking at options to upgrade the application and the main problem I have is in determining how to deal with the crystal report files.
I have successfully upgraded to VS2008, but any version after that doesn't have CR anymore, so my company would have to pruchase CR separately and because the client and my company are both tight, I'm looking at alternatives...
The obvious one is using SSRS. I have never touched it before in my life, but after playing around with it for a bit, I get the impression that it is not very well suited to generating forms with lots of non-tabular content and lots of formatting. Or am I wrong?
It seems that every line has to be drawn separately. There is no (that I can see) accurate way of positioning lines for formatting...
But I'm just a beginner, so I might be getting this all wrong?
If that is the case, are there any other alternatives to CR and SSRS?
I was thinking of maybe having a separate MVC web site project in the solution. Have that generate the layout in html and css with data from my entity model, then view the result in a (built-in or not) web browser. Am I overcomplicating on this?
I really need advice from somebody who's done that kind of thing before.
What SSRS is good for:
Talking to SQL Server, much faster than other products as it in many cases retains the database better when in other programs IMHO they repeat query at times.
Designing collapsable grids and chart objects from datasets. You can have 'groups' that can nest aggregates of collapsed values and can be un collapsed or collapsed on demand based on expressions, parameters, or a recusive parent set.
A web service for deployment ease where you can deploy one or many objects. You can also write add ons for this service with C# and the ReportingService.asmx web service.
You can talk to the web service directly in a 'form' object in HTML and manipulate it's output.
You can schedule reports to send out via email and file saves automatically to clients or internal users.
What SSRS IS NOT GOOD FOR:
It is not event driven hardly at all except for parameters. You cannot click on many things and get other parts on the form itself to update. You may do an 'action' that goes to another location, report, or site. But in essence you are calling a seperate object, not the same instance again.
Multiple layers of reporting. Beyond tweaking tool tips you cannot do 'hover over' reporting without hacking SSRS. You can make javascript windows show other reports but it is not baked in to SSRS. So you are either clicking into new reports or tab stops in a report but not getting hover over quick objects beyond text and expressions that are in tool tips.
What do you want before considering what you need to impement?
I want to input and export things while talking to my database - ASP.NET with potentially HTML 5 or MVC4 if you want to be very new. ASP.NET is made for actively talking to a server and taking commands IN as well as OUT.
I want a form to auto update periodically on a page as a landing site and dashboard - AJAX and Javascript on top of HTML, Java or ASP.NET.
I want to create reports that exist on a Server and can be hosted on a wide variety of platforms in .NET via web service calls - SSRS.
SSRS's biggest selling point to me is it's reusability once you dial a report in. They are pretty easy to create, easy to configure, easy to deploy, and if you get a little advanced in calling the webservice you can get SSRS report objects in other technologies if you want.
There is Crystal reports for VS2010 and VS2012. It is just not shipped with them. You can download the installation from here: http://scn.sap.com/docs/DOC-7824
I am running through the same decision process at this time. There is a .NET product from a company called "Windward" that will allow you to design your reports in Microsoft Office. If you are in the MS ecosystem already or want your users to design reports instead of always calling on you, this might help.
Their template design tool is called AutoTag and you can deploy these template to their .NET based engine in a few lines of code.
I know the question is regarding SSRS vs. Crystal comparison but thought you should know there are other alternatives and some can make life easier
Ryan

Integrating Sharepoint with Quality Center

I am an intern for a company that wants to try to integrate data from HP Quality Center (graphs, dashboards, data etc) into Sharepoint 2010. The whole idea is that once a test case or something is updated through Quality Center; it should automatically update on sharepoint. Any ideas on how this could be done?
Well quality center does have a database behind it, so you could query that via BCS.
OR, for bonus points since QC doesn't offer any web services, you could expose the data yourself using the COM API that they provide. We have done this in-house to tie into our own reporting system. non-SharePoint sadly.
If you want to show QC reports in share point, then you can define the reports in QC, and use OTA (The COM API) to periodically pull those reports and store them in share point.
To find more information regarding the API, just go to help menu, there you can find documentation for both the COM API and for DB structure.
If you want to update data in share point and not show aggregated results, then you can write a workflow script which will be triggered when data is changed in QC. In that script you can do pretty much any thing you want as long as it's COM. So you can go to share point as well and update data there. For workflow documentation and example go to help menu in QC.

Using ETL (non-MS) to get data from Infopath forms stored in Sharepoint 2007

I'm looking at the architecture for a DW project and there will be the need for some manual collection of [structured] data eg the monthly accounting results from a country manager where they need to complete a form and fill in half a dozen values etc.
I really like the idea of using SP and InfoPath for this as it gives the security, the workflow and the customisability etc that mean it can be easily deployed as the client already has SP rolled out. The bit I am less clear on is how, technically, we might interface to the SP workflows and the forms themselves. Ideally the data would end up dropped into a database and we would use our [their!] standard ETL (DataStage, possibly sat on a linux server) via ODBC and pick it up like any other datasource but I am not sure what this requires on the SP side. The alternative would be to get at the XML of the individual forms and pull the info from there.
Are these appaoches feasible? What would need to be set up on the SP side in order to make this integration as robust and seamless as possible? Can anyone point me at docs/reading matter that might give me some more background info?
Thanks,
Dex
First up, accessing sharepoint's databases is never the answer to any integration question. You should treat it as a black box.
So, how should you get the data? Web Services + HTTP. SharePoint offers a large amount of Web services to get at the data you need. If you're working with IP forms, then ultimately you will need to grab the resultant XML file from the document library and parse it to get the data you need. The Web services can be used to enumerate the IP forms, and you can use straight HTTP to grab to xml file. This is probably the approach that would be offered by most experienced sharpepoint people.

Refactoring Crystal Reports: whether to, to what and why?

Report design, generation and maintenance isn't hard, but it is dull. We have a number of legacy (to quite different degrees of legacy) reports in Crystal Reports XI. These are designed for A4/PDF - not necessarily printed, but to be of a predictable layout and there's no possibility of us retiring them any time soon.
All connect to existing stored procedures (SQL Server 2005) to acquire their data. A lot of time has been sunk in getting these reports to look just so. The actual creation of reports is mostly done via the .NET/C# API and exported to PDF. There are a number of locally developed and maintained applications that are stable and handle this process well.
So we like the fact that Crystal Reports is stable, that our apps produce these reports reliably, that the PDF output is consistent and that when the Crystal Reports template is approved and set, it just works.
There are some big problems with this situation though. The biggest being that any changes to the underlying report templates themselves are a huge pain; getting the Crystal Reports template to a point that users are happy is a royal hassle and can involve a long iteration of DTP/graphics/database/reconciliation and myriad other niggles.
Combine that with Crystal Reports being a relatively rare skill and not one people want to admit to, we are trying to think up alternative solutions.
Some thoughts I've started to consider - and any others welcome!
Does Crystal Reports 2008 offer any benefits over XI?
How have others managed a migration away from CR? And what to?
Given the data access layer is well formed, perhaps generate graphs via an Excel service and then import them as graphics to a framework template? Crystal, another - has anyone tried anything like this?
Is Reporting Services any better? (We have some RS skillz but again, another thing that people are loath to actually own up to knowing anything about.)
Are there any layout tools available (preferably with a .NET API) for what, in the old days, would be called Desktop Publishing? If we have graphics/tables/other objects as images that could then be rendering automatically,
Ideally I want to move to a solution where the users are in greater control of the underlying changes, and whether this can be handled programatically within tools that we can provide to them and so that I can be coding rather than editing Crystal Reports templates.
So what other problems are you having with Crystal? Sounds like you want the users to handle the reporting...(don't we all). The problem with that is they never want to use whatever data model is offered. Someone has to know how to query the database. You already have that by using stored procedures. Maybe let a couple users learn basic crystal principals (grouping, sorting, summing, etc) and you write the stored procedure and they format it with crystal. That way you bypass the biggest stumbling block with crystal, which is doing the table joins in crystal.
I have crystal knowledge and think it's fairly easy to use. I wouldn't call it skillz though, more like I know what it can and can't do, so I can save myself a lot of time.
I'm not trying to defend Crystal, but if it ain't broke...
We recently upgraded to VS 2008 on XP. Our users are still running the .NET 2.0 framework on Win2K, and a company-wide upgrade is not in our near future. What we didn't find out until we'd already upgraded from 2005 to 2008 is that the Crystal Reports redistributables that come with VS 2008 only work on XP or higher. Oops. So, we're now unable to edit our old reports because CR will automatically update it to the new version.
What I wound up doing is using our existing XMLSerializer, building a class that holds the report data (lots of string and List<T> properties, essentially), and serializing it to an XML file. Insert an XSL stylesheet declaration that transforms it to HTML/CSS, and open it in IE.
It's wound up being quite a bit faster than Crystal Reports, particularly for development, and I can typically have them just give me a Word document of whatever the hell they want the report to look like, export it as HTML, clean it up, and then use that as a template for what the XSL generates.
It's nowhere near as full-featured as Crystal Reports, but for what we need (XRay and Lab reports and work orders), it's perfect.

Resources