Overview of modeling code for systems that can be used by ThingWorx things and mashups (Integration for PTC ThingWorx)
Using PTC ThingWorx you can create web-based applications (ThingWorx mashups) that can display data from different applications.
When you use ACS to generate Java and C++ code for applications from Modeler, you can set up those models so that ACS generates code to expose data and services that can be used by ThingWorx Things and Mashups.
In addition to generating Java and C++ code, for Classes and Interfaces stereotyped as Remote Things, ACS can generate XML files for Data Shapes, Thing Shapes and Thing Templates that can be uploaded to a ThingWorx server. You can optionally set up a model so that the generated XML files are automatically uploaded to the target ThingWorx server.
To set up a model for use with ThingWorx Things and Mashups, you use the Stereotypes and Tag Definitions that are provided in the ThingWorx profile.
The Electric Car Charger (Java) model that is provided in the Examples database demonstrates how to use the ThingWorx profile in a model. The ReadMe text diagram in the model provides information for generating and building the code, and simulating the system.
Setting up a model to generate code for systems that can be used by ThingWorx things and mashups
To generate systems that can be used by ThingWorx Things and Mashups you must make the following changes to a model:
• Define ThingWorx Remote Things by applying the «ThingWorx RemoteThing» stereotype to the relevant Classes and Interfaces.
• Define ThingWorx Properties by applying the «ThingWorx Property» stereotype to the relevant Attributes.
• Define ThingWorx Events by applying the «ThingWorx Event» stereotype to the relevant Operations.
• Define ThingWorx Services by applying the «ThingWorx Service» stereotype to the relevant Operations and Events.
• On the top-level Class for the system, create an untyped port that is stereotyped by the «ThingWorx ConnectedClient» stereotype.
• For each Class that is stereotyped by the «ThingWorx RemoteThing» stereotype:
◦ Create a Part on the system Class that uses the Class as its type. You can do this by dragging the Classes to the system Class on a Composite Structure Diagram.
◦ Create a Bind Dependency between the Part and the untyped port that is stereotyped by the «ThingWorx ConnectedClient» stereotype.
Seeing how the Electric Car Charger (Java) model has been set up to generate code for systems that can be used by ThingWorx things and mashups
Open the Electric Car Charger (Java) model from the provided Examples database.
In the Packages pane expand the Software package, and then open the Composite Structure Diagram.
On the top-level CarSystem class you can see the untyped port that has been stereotyped by the «ThingWorx ConnectedClient» stereotype. The port is named ChargingPort.
Open the Property Pages of the ChargingPort port, and click the ThingWorx Connected Client tab.
The values of the tag definitions have been set up to work with a ThingWorx Bridge, because the Electric Car Charger (Java) model has been set up to generate systems that can communicate through the ThingWorx AlwaysOn protocol.
However, the values work in a similar way for a ThingWorx server:
• The applicationKey property value would be set to a valid application key value for the ThingWorx server. See the ThingWorx Help for information about application keys.
• The uri property value would specify the following information:
◦ wss for a secure connection.
Note that when it is a non-secure connection, the uri property value would specify ws.
◦ localhost for a ThingWorx server that was on the same computer as the generated system. Alternatively, localhost would be replaced with the name of the computer on which the ThingWorx server resided.
◦ 811 specifies the port.
For a secure connection to a ThingWorx server, the default port number is 8080. For a non-secure connection to a ThingWorx server, the default port number is 8443.
• The IncludesCommsBroker property should be set to False when only generating code for systems that can be used by ThingWorx things and mashups.
The Car class has been defined as a ThingWorx Remote Things by applying the «ThingWorx RemoteThing» stereotype to it. If you select the Car class in the Software package and view its Property Pages, you can see that a ThingWorx RemoteThing tab has been created for the applied «ThingWorx RemoteThing» stereotype.
On the Composite Structure Diagram you can see a part named m_Car that uses the Car class as its type.
You can see that a Bind Dependency has been created between the m_Car part and the ChargingPort port, which will result in ACS generating Remote Thing code and XML for the Car class.
If you expand the Car class, you can see that the «ThingWorx Property» stereotype has been applied to its IsConnected attribute, and the «ThingWorx Service» stereotype has been applied to its IncrementBatteryLevel operation.
