Operator Advisor: Best practices to deploy to a new server

[jasperlg]

Hi, 

We are implementing the Operator Advisor with an actual client, using the OA as an accelerator of our project. We still have some questions around deployment, which are not very clear to me in the guide.

What is the recommended way of doing a OA deployment? I mean we will have allot of additional tables and AP's added to the current data model. What are the best practices on how to update the database when we go from one environment to another? Should we write a service that updates the entire databasemodel?

Thanks for the help on this, 

Jasper

[vranganathan]

I am not sure whether your question is around whether to port the schema or data? If schema and data, then you can simply import the database (I would recommend you to create a separate database for OA). If  you are creating the Schema, there are couple of options, Running CreateTables and/or with the help of scripts.

If you can brief more on your specific intent, we can provide additional details.

[jasperlg]

@vranganathan,

Thanks for your reply. I should explain our situation a bit more I believe. With a transfer from environment I meant a transfer from a dev environment to a test environment to a production environment, so I want to recreate the tables that I created (and delete the ones I deleted) in my production environment. I've tested the CreateTables function, it doesn't add the _AP properties if the _AP table already existed from before in the database. What kind of scripts are suggested as a best practice to update the database model? Scripts that compare my DataShapes with the tables in the database? Or scripts that just try to push all DataShapes into the database? 

Kind regards,

Jasper

[vranganathan]

For all entities and customizations, I usually use extensions to move all my entities/customizations. Given that some of the _AP objects (which are the only editable objects) coming from OOTB extension, we had trouble in importing as part of the custom extension. You should able to tag them differently, export them and manually import them. Rest of the entities should be part of custom extension.

- I use the eclipse to build my extension using the plugin provided by Thingworx

- I also assign all my entities to a project. Then I export to source control. It gives me a exact structure I need for eclipse. Also there are extensions available which can push it to Git.

- You can copy the exported XML files from repository to eclipse project or pull directly from GIt into eclipse.

- Then build the extension and deploy. Every time you deploy the extension, make sure to increase version number

- For OA data, I would stick to database level scripts for now.

Thanks,

Varathan

[jasperlg]

@vranganathan, 

We will do ThingWorx upgrades the same way, only I put my _AP DataShapes in my project so they import allong. But the issue is not within ThingWorx itself, it's with updating the database. I wouldn't like it if I needed half a day to put my project from dev to test to prod, just because I need to rework my database model with services. But as I understand it, it's the only way. 

Thank you for your time. 

Jasper

[vranganathan]

You need to drop the table first before running the CreateTable. I tried and it worked for me.

Thanks,

Varathan

[jasperlg]

@vranganathan,

That would not be the best solution I guess, since the customer would lose all of its production data this way...

Jasper

[vranganathan · Accepted solution]

This create table service intent is to just update that specific table not the entire database. By default _AP will have only UID column and no data. Typically no other property predefined. The expectation is data model will be finalized before going to the production first time. That may not be the case always.

Our intent is NOT to rebuild another database tool. We want to provide what is needed the most to support model driven approach. If you are making these changes(if you are adding first time to _AP I don't see an issue) after the first release, our recommendation is to use SQL to update the given tables. 

I hope this helps. 

[jasperlg]

"our recommendation is to use SQL to update the given tables"

I'll take that as a solution.

Thanks.

Kind regards, 

Jasper