Hello everyone,
This post is meant to fill the gap that Basic Rules of ThingWorx Development is having.
You can follow these rules even before starting the development process and keep them in mind to have an organized and easy to maintain application.
I will update this post in the future with more best practices and advice.
Best Practices and suggestions:
In order to have a clean and quick progress in any project the approach should be modular. If the modular approach is implemented also the development process should be thought of in a modular way.
This will give much needed independence to each individual developer especially if the team concurrently works on the same instance.
Some rules need to be in place in order for the project to be as smooth as possible:
- Every developer must have its own user. This is more important when developing on the same Thingworx instance but it’s a good practice when developing on individual instances as well.
- Every developer will be responsible for complete modules, from the respective screens of the GUI to the functionality services and business logic.
- If concurrent work on the same Entity needs to happen then communication between the developers and time sharing on that entity is needed without developers overwriting each other’s code. Don't decide to go into edit mode if there is someone else already editing. That will get you to a dead end.
- For the point no. 3 to work, after editing an Entity each user must press the Cancel Edit button and leave that Entity in View mode.
- When searching for services or properties developers should avoid pressing on the name of the Entity which is a link that directly opens the Entity in Edit mode they should rather use the button with the magnifying glass
to the left of the name that will then take them in View mode. - As a result of the modular approach each module will have its own Utility Thing that will contain services, properties, events and subscriptions that help develop the functionality for that module.
- Each module will have its own tags and the format could be:
<Client_Name><GUI/Business><Module_Name>
8. The integration of the modules will be done in the Master by a single person in charge with that master or by each developer at a time.
9. Depending on the case the Data Model could be treated as a module in its own right or can be integrated in each module if the project permits.
How to manage multiple users working on the same code in Composer:
(Thanks to Pai Chung)
Currently Thingworx within the development environment allows you to heavily document all your works, that includes ‘Save with Comment’. We encourage the use of the Documentation field and the ‘Save with Comment’ option.
However generally development is not isolated to one environment.
Thingworx provides several ways to back up the information.
Backup – this is a true Database backup that creates an additional database in ThingworxBackupStorage and basically can be used as a restore, by copying it back into ThingworxStorage
Export to ThingworxStorage – this is a full model export (with or without data) that can be triggered at any time. It can use Date filters to export according to Modified date. This is server side.
Export to File – this allows you to export a single or group of entities/data according to a variety of filters. This is client side.
Export to Source Controlled Entities – this allows you to export to a file folder structure or Zip that can be easily checked into a Source Control system.
How to approach Source Control:
- After some initial modeling, Export to Source Control Entities and check this into your Source Control system
- From this point forward all developers have to follow a Check in/check out process
- Every time an Entity Group security setting is made, Export to ThingworxStorage and also check that into Source Control overwrite the previous.
- All in use Extensions should be in one zip and also reside in Source Control
To do a restore or deploy
- Install the Platform
- Install extensions
- Import from ThingworxStorage the last Export checked in
- Import each single Entity file, in the proper order.
- Import each single Data file
6. Clean up dead entities (if there is a reference list)
Additional steps to take to help safeguard the development.
- Make sure the Automatic backup is running
- Export the Entity to a subfolder with the Date of the Edit
3. Full Export to ThingworxStorage to run every day after development stars - This can be scripted and triggered by a timer or scheduler subscription (<Server>/Thingworx/ExportDatabase/?WithData=true). In this way you have a backup with everything that was on before you started working each day so you can roll back if an error occurs.
CONTINUED 7 Sep 2015
How to organize wiring needs when developing the GUI:
Starting from the idea that we can divide the GUI elements in Display Elements and Action Elements I have created a common form in order to be filled with information necessary for the wiring of that Element.
UI Element Type | Display Element / User Action Element |
Thing Name | Name of the thing where data / service is found |
Service Name | Service inside the Thing that returns the data / is the subject of the action |
Property(ies) Name | Thing property / column name (when service returns an infotable) for Data Elements / Input parameters for the service to be run if User Action Element |
Additional Logic | Additional information regarding the way the information sources change when preconditions are met. Usually means new services or mashup logic is needed. |
I suggest that an additional companion document to the GUI description document to be created. This document will contain the previous form (table) for each screen/slide so that the work on specific screen/slide could be done independently.
To be continued...
