Migrating objects

changa

Member
Hi all,

does anybody know if it's possible to use Change Assistant to create an ESU?
I need to migrate customized objects from 8.11 to 8.12 (different installations, not the same one).
Any suggestion?

Many Thanks In Advance,
Lisa
 
Boomerang.

Go to www.everestsoftint.com and look at the "Boomerang" product page. This is a replacement for Product Packaging - and the pricing is extremely reasonable (hundreds, not thousands, of dollars). You can migrate between any version of oneworld (in an upward direction).

Hope that helps. Alex (the author) is often on this board and supports the community very closely.
 
I know about it and if it was up to me I would buy it immediately. Unfortunately my boss asked me to discover how to use Change Assistant to create an ESU for migration!!
I knew also about Product Packaging, but never heard about Change Assistant suitable for that purpouse! And not finding anything useful on Oracle Customer Connection! At least I need to be sure Change Assistant is not really a possible way.
However thanks for being so quick in answering about a such known topic as Boomerang.
smile.gif
 
[ QUOTE ]
...my boss asked me to discover how to use Change Assistant to create an ESU for migration!!

[/ QUOTE ]

I thought this was a typo when you first asked this. Of course you cannot use change assistant to create an ESU - all it is is a download tool !!!! It doesn't really even integrate to OneWorld !!!

All ESU's at JDE are created using product packaging. Its not easy to set up - and it certainly doesn't provide the ability to extract from one version for a different version.

No, the ONLY way I know to do that is to use Boomerang. Tell your boss that the few hundred $ he just spent in hours looking for an imaginary solution could easily have been put towards boomerang and you would have had the solution working by now.
 
[ QUOTE ]
I thought this was a typo when you first asked this. Of course you cannot use change assistant to create an ESU - all it is is a download tool !!!! It doesn't really even integrate to OneWorld !!!

[/ QUOTE ]

Change Assistant is in fact more than a download tool. It can be used to apply ESU's to your Deployment Server via the deployment environment, and with the proper release, automate many ESU special instructions.

Granted, this doesn't mean you can create ESU's with it...
 
Are you able to make the two installations "talk" to each other? In other words, do you have physical network access between the two installs?
 
Yes, we have physical access... hmm I am curious to see in which direction you are going. Do you think there's a way to do it?

By the way, completely agree with altquark about everything you said, even if he is still my boss and at least I have to try to follow his "madness"!
smirk.gif
 
[ QUOTE ]
Yes, we have physical access... hmm I am curious to see in which direction you are going. Do you think there's a way to do it?


[/ QUOTE ]

Yes - I know there is a way to do it. I just did it. I will post the process once I have time to fully test all objects. Transferring objects between releases is not some mystical black art, you just need to know the proper configuration steps and have security between the two releases.
 
[ QUOTE ]
Yes - I know there is a way to do it. I just did it. I will post the process once I have time to fully test all objects. Transferring objects between releases is not some mystical black art, you just need to know the proper configuration steps and have security between the two releases.

[/ QUOTE ]

Really looking forward your post!!
Thanks,
Lisa
 
Before you begin, I think it would be a good idea for you to review Solution ID 200986393. The jist of their note is, and this applies to Boomerang just the same, you should be careful to use this process specifically for custom objects. Also be mindful of major specification changes between releases as well as architecture changes (such as betwen ERP 8.0 and EnterpriseOne 8.9). I can add that you should capture all object dependencies before proceeding down this path, but once you have your requirements, it should work perfectly fine.

Although I did not attempt an OMW transfer from 8.11 to 8.12 (need a working system outside of a sandbox area for that), I was indeed succesful in my attempt to transfer from 8.11 SP1 to 8.9. In theory , it should work from 8.11 SP1 to 8.12.

This process is, for the most part, documented in Document ID OTT-03-0025. Unfortunately, this document is apparently no longer on the Customer Connection. I can't believe it, but I do have a hard copy of the document from years ago. There are a number of ommissions, but with sufficient CNC knowledge you can fill in the gaps. I've added a few of my own additional steps to their process, as you will not be successful if you simply follow the steps in OTT-03-0025 to the letter.

The process is (assuming you use the standard pathcode and environment naming conventions, e.g. DV811 & DV812):

1. Create a database user account in the target JDE release database. For instance, create PSFT in the 8.12 database and grant the appropriate role to PSFT, such that it will have the same access as the JDE user in the target release.

***It is important that you set the password to be the *same* as the PSFT user in your 8.11 release. If you fail to do this, you will see thousands of database login prompts when you attempt a transfer from 8.11 to the target release. You will also see a few of these when you attempt to add OCM mappings in the System - 811 OCM table.

2. Create multiple data sources which point to your target database. These are specific to the target environment (e.g. DV812) and include System, Control Tables, Central Objects, Versions, Data Dictionary and Object Librarian datasources. Yes, you will see two "System" datasources in the the Database Datasources Application. This is fine because your clients and servers will point to the proper System Datasource in their JDE.INI and JDBJ.INI files.

3. Create a path code in the source release which mirrors the target release pathcode. You should include the proper deployment server name and path.

4. Create an environment for the above path code. This does not need to be an environment complete with all OCM mappings, simply an environment which points to the pathcode. For instance, if you are transferring from DV811 to DV812, create an environment in your 8.11 release named DV812 and point to the DV812 pathcode you created in the previous step.

5. Create *PUBLIC active OCM mappings for the F9860, F9861, F9862, F9863, F9865 and F983051 tables. (I also included Central Objects tables in the OCM.)

6. Use the Release/Data Source Map application (P00948) to define the release value for the Data Sources in step 2.

7. Use the Release Compatibility Maintenance application (P00946) to define the data sources and target release values.

8. Create OMW Transfer Activity Rules to transfer from the source environment to the target release envrionment.

9. Create OMW Allowed Action Rule to enable transfer from the source environment to the target release environment.

10. Create new status code to transfer project to the target release.

11. Logout (to clear your cache) and back in again. Test your transfer process using OMW. If you see errors, check for the source and examine the previous steps for anything you might have missed.
 

Attachments

  • 124452-TransferAcrossReleasesExample.zip
    9.2 KB · Views: 162
I am going to have a go with it.
So kind of you giving me Excel example files as well!!!
THANKS!!
smile.gif
 
Hi Guys,

I migrated the objects from 8.11 to 8.12 as per the mentioned procedure. The migration went through fine without any errors, however while to check out the objects it does not recognize the format of the specs. Similary while trying to do a package build for the migrated objects it does not recognize the spec format & hence pkg build goes into error. Please let me know if any one of you has faced this issue before Thanks.

Enterprise One 8.12, RHEL, AS400, ORACLE 10G.
 
Boomerang sounds like a good idea.

As I stated, the migration from 8.11 SP1 to 8.12 was a theory. I can state with hands-on knowledge that the migration from 8.11 down to 8.9 worked for me. I haven't tested 8.9x -> 8.12. Perhaps sometime soon I can find the time.
 
Go with Boomerang. Great tool, good price, uses OMW for documentation in both releases, quick and simple to use, very accurate for transferring custom objects. Alex provides great support with updates and additional help if ever needed. The best tool for this process out there!!
 
You could either waste hundreds of hours trying to convert/merge/upgrade objects between versions - or a few dollars on a very worthwhile tool. All organizations that are upgrading/updating or doing in-depth development work should have a copy of boomerang available..
 
Did someone mention Boomerang (hee-hee).

It really is a cost savings vs. the time and frustration figuring out and troubleshooting other methods.
 
Back
Top