Pinned topic What are steps to export database configuration?
I am running SCCD 7.5. Can anyone offer advice on the steps to export single objects, domains, actions, and expressions? The Migration Manager method is very confusing and I am just trying to export the above individually into the production environment.
Thanks in advance for your knowledge,
Re: What are steps to export database configuration?2013-03-18T15:50:52Z in response to lesleyajohnson76Where do you want to export it to? And how many export files do you want to work with? The Migration Manager method is a packaging method. As long as you know which configurations you want to export, you put them all into one package.
Re: What are steps to export database configuration?2013-03-18T16:16:57Z in response to agrippaHi, We are looking to export them to another instance server. Because we find the Migration Manager confusing, we were looking into exporting the object, or database configuration, individually. Any advice on how to do either way?
Re: What are steps to export database configuration?2013-03-18T16:34:52Z in response to lesleyajohnson76Hi Lesley,
Follow these steps:
1. Open Migration Collections application.
2. Create new empty collection.
3. Click New Row in the Configuration table window.
4. Click the Details icon in the Application field. This will bring up list of applications including Db Configure, Domains, Actions, etc. Navigate to the application of your choice. Select the record you're interested in. Return with value.
5. Collection now has an entry. save collection.
6. When you're ready with the collection (having added more configs into it), run the Create Package Definition action.
7. This will generate a template package definition. Access the Package Definitions tab of Migration Collections to review entry.
8. From this tab, you can jump directly into Migration Manager. Approve the definition.Access the package tab and click Create.
9. Set up a target (either database or file) - most customers use File. A ZIP file will be created on the server of the package. You can download it to client workstation.
10. Click Distribute and select the target you just created. The ZIP file is generated and placed into a file system location on server
11. Click Download icon to the right of the package entry in package tab to get a local copy of the ZIP file on client workstation.
12. Log into the Target environment UI as administrator.
13. Access Migration Manager app.
14. Click Upload button and select the ZIP file you downloaded from the source product environment
15. Having uploaded, click Deploy button on the toolbar. Confirm you have a Database backup in the Deploy Package dialog and click the Deploy button in the dialog.
That's the overall procedure. Any other options on the table will involve much more work on your part than Migration Manager itself.
Also, as Bradley pointed out, the Redbook is completely scenario based, just take the Data Dictionary chapter and review the steps being executed.
Exporting - importing single objects, via single files is too cumbersome and you will quickly loose traceability of your migration proces.
Re: What are steps to export database configuration?2013-03-19T16:04:22Z in response to agrippaHi, agrippa,
Your instructions for migration are great. However, I am stuck at Step 9. After I hit create, I am confused as to how to create the file. I feel like I am missing a step to create Compiled Sources or something. It won't accept my entry for compiled sources. Did I miss a step?
I have attached some screenshots to show where I am in the process.
Re: What are steps to export database configuration?2013-03-19T16:14:00Z in response to lesleyajohnson76Lesley,
The step you're looking for is "Distribution". Ignore Compiled Sources. I am sure you have no PDF, JPG, or other "file" to attach to the package. Everything is configuration extracted from the database.
For step 9: Find the toolbar button called "Manage Targets" in the Migration Manager app. Click it. A popup window will appear with table window. Click New Row. You can define this logical target to be of type DATABASE or FILE. DATABASE implies that the package data (XML formatted) will be pushed from the source database to target database directly using JDBC connection. Most clients do not use this option. Instead they extract the package as ZIP file. ZIP file is created for you if you define a target of type FILE. So go ahead and specify Type to be FILE. Since you chose FILE you must point to a folder on the server-side where Migration Manager can safely dump out the ZIP file. For Windows boxes, I usually pick c:\temp. For Linux / Unix, /tmp should work. Save this "target definition". Return to the Package tab for the particular package and click Distribute button. A Distribution dialog will show up listing the target you just defined. Select this FILE target and click OK. A ZIP file will be created on the server. You can now download that file to the client workstation by clicking the Download File icon to the right of the package row in the Package table window.
MGer 2700036XE65 PostsACCEPTED ANSWER
Re: What are steps to export database configuration?2013-10-03T09:00:11Z in response to agrippa
I can see valuable information here.
I have a scenario where I need to migrate all the configuration done on my production environment to a new environment (security groups,person groups, domains, actions,roles, workflows,communication templates...)
Should I follow these steps or there is any other procedure to follow?
Thank youUpdated on 2013-10-03T09:00:22Z at 2013-10-03T09:00:22Z by MGer
Re: What are steps to export database configuration?2013-10-03T11:27:52Z in response to MGer
If the scope of your configuration is "everything" from production, I would suggest using a snapshot approach rather than collections. Define 3-4 primary packages: 1 data dictionary, 1 application (including start centers), 1 everything else. Set the where clause for object structures to be 1=1 to collect everything. The packages will be pretty large ones.
On the other hand, if "everything" means not only configurations but also application data such WOs, Job Plans, POs, etc, then you are better off simply taking a database export.
Check the Migration Groups app and review what is supported and what's not to determine your path.
MGer 2700036XE65 PostsACCEPTED ANSWER
Re: What are steps to export database configuration?2013-10-03T13:29:59Z in response to agrippa
Thanks Agrippa for the reply.
My concern is to have an environment with configuration similar to the production one I have.
I don't need the application data but the data used in configuration that I have mentioned before.
I appreciate any detailed procedure you can provide for that.
This reply was deleted by Demonic240 270005X5Q1 2013-10-04T14:42:41Z. Reason for deletion: replied to wrong post
Demonic240 270005X5Q126 PostsACCEPTED ANSWER
Re: What are steps to export database configuration?2013-10-04T14:42:48Z in response to agrippa
Is this the recommended approach for overwriting our test environment with a snapshot of production? Our three environments are out of sync and I'd like to make them all the same.
BKDowning 0600024FX615 PostsACCEPTED ANSWER
Re: What are steps to export database configuration?2013-03-18T16:18:22Z in response to lesleyajohnson76Howdy... My suggesstion is to work with this publication: http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0945.html?Open This use case scenario will allow you to define what you are wanting to migrate and move it in the most efficient way possible. If all you want to manage is the data dictionary there are wys to do that. You may need several packages or not. You may want to use collections, which can be more efficient and still require multiple packages. Depending on the data you are moving and the validaiton relationships you will likel have to use at least two packages. Keep in mind tht the more data you put into the package the longer the validation will take and therefore the longer it will take to process the entire package.
If you have moved data in one change window and you have proff of that migration, then as long as that data has not changed, you need not send it again. Therefore it is possible that you can send small subsequent packages and not require data that would normally be needed in order to have data-validation work properly.