Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X
Team, Would it make sense to use Tableau to create a dashboard that displays Windchill stats? Tableau would possibly access the WC ODATA REST API using https://www.tableau.com/developer/tools/web-data-connector. Has anyone got a start on developing a connection like this? Otherwise I would start from scratch. What would be the biggest challenges in this project? cheers -- Rick
Windchill Help says:
Aha, that URL should be:
https://domain.com/Windchill/servlet/odata/v6/ChangeMgmt
Now Tableau and Windchill are talking!
Biggest challenge I see with using the REST for reporting is that not everything is available. I've been using PowerBI to report Windchill stats, but based on Query Builder reports rather than REST. QueryBuilder is much more tailorable to the specific reporting need and ensures you don't have any gaps in data availability like with the REST framework. As the "rest" of the REST framework is fleshed out I would consider re-evaluating, but for our needs it typically isn't enough.
We are trying to use PowerBI as well.
Are you using SQL queries and connect to the production Windchill DB or did you setup table replication and point PowerBI to the replicated DB?
We do something similar, running a QB report from a python program. The Windchill URL is domain/Windchill/servlet/WindchillAuthGW/wt.enterprise.URLProcessor/URLTemplateAction?parameters
You can learn how to use the parameters with the help of chrome:right-mouse->inspect in ReportBuilder etc. But there are problems: if the description field has newlines that messes up the CSV. If you choose to get the data in XML then any non-ascii character in your description field messes up the XML file. So we use QB just to run a simple join, and get the description fields via ODATA. That makes for a complicated python program.
Agree on the XML. I started with that output and ran into the same issue with the characters. Then I figured out how to use the CSV and life is great. I haven't experienced any issue with the new line characters yet. Regarding the parameters, the way I do it is to first set up the QB output as HTML and run it once on a small constrained sample. This gets you the URL that contains the parameter(s) strings you'd need. I copy this URL and then change the output to CSV and use the source call in PBI that I mentioned. Since I now have a URL that contains parameters I can replace my test values for them with actual PBI parameters. This allows me to make a dynamic reporting source, i.e. one QB design that can be used for multiple PBI use-cases within the parameter definition. Like a project name, or user name, etc can be feed into the parameter on the PBI side.
Agreed, the OData WRS does not make everything available. You cannot do a join quite as easily as QB does it. In certain cases it is easy with $expand Context/Name or $expand AffectedObjects (sp). Other joins seem to be impossible in OData.
Oh, and the current sore point is that we don't see how we can get the Rich Text RTF fields in OData. That is with OData called from python.
Worse still, Tableau's Odata connector does not seem to support the $expand= flavour of join. Comments please! Maybe I need to use TabPy and some custom python to make a bridge between WC Odata and Tableau.
Team
Sorry for bumping this question up again. Maybe we need to use the Tabpy project, because the Odata connector does not seem to let us do the '$expand=' that we need? And we would need to build a WC specific layer on top of TabPy, or is there a simpler way?
cheers -- Rick