If you followed the links from my previous article, you probably read the article “How to Embed ThingWorx mashups in Windchill”. While this is more detailed explanation of steps that needs to be done, there is one (two, actually) sentence that claims the following:
“In addition, the ThingWorxController handles giving the mashup the oid and ContainerOid as URL parameters (where applicable). The mashup would then have to make the necessary calls (using Windchill REST services) to acquire any additional data that is necessary for displaying the mashup. For more information about mashups, see the ThingWorx Help Center. Currently it is not supported to pass additional parameters to the mashup via the action URL.”
So, where are those parameters and how to access them? If you attended one of the PTC courses in relation to Windchill platform customization, you were probably introduced with logic how Windchill handles the folder navigation, data navigation and what is the logic behind it from the software platform perspective.
If you take a better look to the URL itself while you are navigating through the Windchill you will notice that there are always additional parameters passed to the platform via URL.
Screenshoot 1 – URL Parameters
Very short explanation:
By introducing and utilizing URL parameters in Windchill platform, system enables web pages to customize and support different views (and their amount) based on parameters values. URL parameters are dynamical values, thus amount of flexibility that can be exploited and applied on the page with different views is huge. URL parameters also have a significant role in REST API calls, but this is topic for some other article.
Back to our topic …
In our example, we have the following parameters (URL parameters are usually after question mark in URL string):
ContainerOid=OR%3Awt.pdmlink.PDMLinkProduct%3A128942&oid=VR%3Awt.part.WTPart%3A129319&u8=1
For us, in most of the cases we will be interested in following parameter:
oid=VR%3Awt.part.WTPart%3A129319
Or to be more precise:
oid= VR:wt.part.WTPart:129319 - %3A is URL Encoding for ":"
In the sentence that I mentioned above it is written:
“The ThingWorxController handles giving the mashup the oid and ContainerOid as URL parameters (where applicable).”
Let us verify that. Fire up the ThingWorx, open the mashup and let us add two more labels, one with the text “oid value from Windchill” and the other one as a location where we present the actual value.
We also need to create mashup parameter and name it with the same name as URL parameter, oid, and bind the parameter with second label that we created.
Screenshot 2, 3, 4 – Preparing mashup
If we save the mashup, click “View Mashup” and add URL parameter oid with some arbitrary value, we can see that the value is indeed passed to ThingWorx mashup automatically.
Screenshot 5 – Mashup test
And if we open the Windchill and examine our custom ThingWorx action that we embedded into, we do see the real oid value that is passed to ThingWorx via URL parameter.
Screenshot 6 – Mashup in Windchill
The result
Now, what can be done with this value? What we get from Windchill is actually part Version ID (the last part version, to be precise) and we can use this ID to query Windchill for more info via ODATA API interface or utilizing directly integration run-time.
If we query via ODATA API, we can use the following API call:
https://xxx.yyy.xy/Windchill/servlet/odata/v3/ProdMgmt/Parts('VR:wt.part.WTPart:129319')
and using the proper authorization in a form of username and password, we are getting the following response (JSON):
{
“@odata.context”: “https://xxx.yyy.xy/Windchill/servlet/odata/v3/ProdMgmt/$metadata#Parts”,
“CreatedOn”: “2018-11-23T19:38:20Z”,
“ID”: “OR:wt.part.WTPart:129320”,
“LastModified”: “2018-11-23T19:38:20Z”,
“AlternateNumber”: null,
“AssemblyMode”: {
“Value”: “separable”,
“Display”: “Separable”
},
“BOMType”: null,
“CabinetName”: “Default”,
“ChangeStatus”: null,
“CheckOutStatus”: “”,
“CheckoutState”: “Checked in”,
“Comments”: null,
“ConfigurableModule”: {
“Value”: “standard”,
“Display”: “No”
},
“CreatedBy”: “Site, Administrator”,
“DefaultTraceCode”: {
“Value”: “0”,
“Display”: “Untraced”
},
“DefaultUnit”: {
“Value”: “ea”,
“Display”: “each”
},
“EndItem”: false,
“FolderLocation”: “/ProductView Demo”,
“FolderName”: null,
“GatheringPart”: false,
“GeneralStatus”: null,
“Identity”: “Part – PV000002, ProEngine, A.1 (Design)”,
“Latest”: true,
“LifeCycleTemplateName”: “Basic”,
“MaterialNumber”: null,
“ModifiedBy”: “Site, Administrator”,
“Name”: “ProEngine”,
“Number”: “PV000002”,
“ObjectType”: “Part”,
“OrganizationReference”: “{“type”:”text”}”,
“PhantomManufacturingPart”: false,
“Revision”: “A”,
“ShareStatus”: null,
“Source”: {
“Value”: “make”,
“Display”: “Make”
},
“State”: {
“Value”: “INWORK”,
“Display”: “In Work”
},
“Supersedes”: null,
“TypeIcon”: {
“Path”: “https://xxx.yyy.xy/Windchill/wtcore/images/part.gif”,
“Tooltip”: “Part”
},
“Version”: “A.1 (Design)”,
“VersionID”: “VR:wt.part.WTPart:129319”,
“View”: “Design”
}
And from here, we can further utilize the other ODATA API calls to build interface that can improve Windchill as a platform or build our custom solutions.
That is all for today. Stay tuned for more.
