Solve export/import property overwrite

[iguerra]

I use some things as a library container for some specific functions

On those things I have services and properties.

I also have sandbox and production cloud hosted instances.

I develop on sandbox then export to production when all is OK ... as all probably do

The problem is that properties contain "local parameters" and the values are different between sandbox and production.

So ...if I export from sandbox and import to production, I could overwrite the right production properties values !

Note that this overwrite may happen also if I export a thing now "as a backup", and import it again after some time

What is the best way to avoid this ?

• May be I could work with thingshape instead of writing directly on the "Library thing" (and export-import the shape instead of the thing ), but this will make a little more complicated and unnecessary for a single thing (shapes are useful for usage on many things).
• Or I could bind properties of the "library thing" to another thing ... don't know however what happen with bound properties values after export-import of the "library thing"
• or use a datatable for storing values ....

It would be helpful to avoid overwrites ... a checkbox "skip import value" for each property (on the Aspects section) that will avoid the overwrite of the value during an import procedure.

[slangley]

Hi @iguerra.

A couple of possible solutions:

1. You could use tags/projects to filter the entities for export/import
2. You could store the environmental values in a data table for update after completing a migration

Regards.

--Sharon

[iguerra]

1. I frequently use tags to export just some objects, this just to create a "block" and export in a single operation many objects. But this will not avoid property overwrite when importing those objects on the target application.
2. which enviromental values ? My problem is with things properties ...
   I wasn't speaking of a whole migration/cloning from sandbox to production ... I never made this. But just export-import of a module or some things for an update.

[slangley]

Hi @iguerra.

I wasn't referring to cloning either--just a migration of specific entities from one environment to another.  Can you give us some examples of the property values for local parameters that should not be overwritten?  We assumed these were environmental parameters (prod, dev, sandbox, etc.). If so, storing these values in a data table for update after completing an export/import process, may be the best solution.

In regard to your suggestion for a checkbox to "skip import value" for a property, I see that you have already posted your suggestion on the ThingWorx Ideas board.  With enough votes, your idea may be considered for a future release.

Regards.

--Sharon

[iguerra]

Hi Sharon

I may have just as example, a datatable with local properties, a counter (used as incremental key for adding entries) , or a infotable property to contain some user data ... or statistics for example.

This structure is the same on sand and production, but they have different values.

If I export this datatable from sand (not the data ..just the thing because I updated something like adding new property or updated a local service) and import into production, the production will get the property values of sandbox, causing possible errors or other effects.

[slangley]

Hi @iguerra.

Hopefully some of the Developers in the community can respond to this with suggestions.  At a minimum, however, you need to identify which properties vary between environments and determine the best method for update following your import.  This could include many possibilities, such as manual updates, REST services for updating the appropriate values, or as initially suggested, a data table in each environment containing the relevant values.

Regards.

--Sharon

[iguerra]

Hello Sharon

I don't think it is a question of which properties vary between sandbox and production ... these are properties, and so these can be different from sand and prod.

The problem I have happens when I export a thing from sandbox to production: properties of the exported thing will overwrite values of production.

This mainly happened with library things, where I have properties and services
Now I'm solving by using thingshapes to define properties and services even on "Library things" ... so I'll export the shape instead of the thing ... so the properties will not be overwritten on the production thing instances.

[Constantine]

Hello @iguerra,

We're solving this issue in the most straightforward way -- we created a thing called SystemUtility, with a service "PostImport", which takes "env" parameter. Inside this service we initialize all configurable things based on the parameter, just in a basic switch. Our CI job triggers this service at the end of deployment, supplying correct "env" parameter (dev / integration / preprod / prod). All passwords are managed in CI and supplied as additional parameters, side-by-side with "env".

/ Constantine

[slangley]

Hi @iguerra.

If one of the previous responses answered your question, please mark the appropriate one as the Accepted Solution for the benefit of others with the same question.

Regards.

--Sharon

[iguerra · Accepted solution]

I solve now the problem as on my first post

I implement in this way:

• I have the Thing instance, eg. MyLibrary
• I have also a thing shape, eg MyLibrary_TS. 
  MyLibrary thing uses MyLibrary_TS as Thing shape
  
  

when I work on sandbox and I add or change properties/services I work on the ThingShape, and I export to production just the TS ... not the thing instance ... so the production "local" thing properties are preserved after the import procedure.