For deploying custom tables that were created using Cloud SDK, I’ve now gotten to this point:
Does anyone have any best practices yet for using Solution Workbench for this?
Here’s what I’ve done so far; it seems to have worked:
I used “Service Designer” to create a service named ProdLineCode_c, as follows.
(The thing with “List” in its name gets set up automatically in Service Designer, it isn’t a real table in the database. This creates just one real table in the database, named ProdLineCode_c.)
To deploy this to a different environment, I used Solution Workbench to create a solution with
Two items of type “ZDataTable” - one for each “Table” shown above
Two items of type “ZDataSet” - one for each “Data Set” shown above
One item of type “ZBODef” - for the “Service” (that is “ProdLineCode_c” shown above in blue letters)
Intalling the solution does seem to work. Is there anything else I should know to improve on this?
Does anyone know of a way to delete this table/service from the destination environment after installing it there, without using Service Designer?
Agreed, data model regen is needed at least twice: once on the source system (after using Service Designer, before building solution), and once on the destination system (after installing solution).
I think things are working OK now – I can get to the table via a BAQ. I haven’t built an app studio layer for it yet, I guess that’s something else that should normally get included in solution workbench.
To update the above information: after installing solutions containing an SDK-developed table/service/BO in the new environment, and after doing a data model regeneration in the new environment, it is then necessary to use the classic “Solution Designer” in the new environment to look up the service and use “Actions > Generate Service”. After that is when you restart the application pool or restart the app server.