Setting up two environments with different Business Data

timallen

timallen

Well Known Member
(OneWorld Xe, Update 6, SP20, SQL Server 2000, DS/ES W2K)
Yesterday I had to set up a second propotype environment based on PY7333. The characteristics the client wanted were these:
- Must use the same objects as Prototype
- Must have a separate, blank Business Data data source

It turned out fine. Here are the steps I took to do this:
SQL Server:
- In SQL Server, created a new user named NEWCRP to be the owner of the new database.
- In SQL Server, exported the SQL necessary to create the JDE_CRP database. I specified that it *not* create any tables or views. I edited the resulting datafile, replacing all instances of JDE_CRP with NEW_CRP. I also copied all statements granting permissions to the user CRPDTA and pasted them, and change the user name to NEWCRP.
- I ran the resulting SQL, which created the database and granted permissions to the users.
- I modified the user NEWCRP to have db_owner privileges on NEW_CRP.
- I created an ODBC data source on the Enterprise Server for Business Data - New.

Windows:
- I created a new ODBC data source for NEW_CRP on a the machine I do package builds from (*not* the Deployment Server).

OneWorld:
- In Database Data Sources (P986115|ZJDE0002) I copied the Business Data - CRP data source to Business Data - NEW, and made changes to the data source to point it at the new ODBC data source for NEW_CRP. I did this for both System and Server Map.
- From Environment Master (P0094|ZJDE0004) I copied the PY7333 environment to PYNEW. I unchecked the "Copy *Public Records Only" option, because our developers have some mappings I didn't want to lose.
- In Object Configuration Manager (P986110|ZJDE0001), in the System mappings for the PYNEW environment, I created a new mapping for DEFAULT TBLE *PUBLIC and mapped it to the data source "Business Data - New".
- One problem here-- there were no mappings for the new environment in the OCM mappings for Server Map. I copied the old server map OCM mappings to the NEWCRP environment with this SQL, connected as JDE:
use SVM7333

insert into F986101
select
'PYNEW', OMAPPLID, OMOBNM , OMDATP, OMDATS , OMUGRP , OMOAPP ,
OMDATM , OMOVRE , OMSY, OMSTSO , OMPID , OMFUNO , OMUSER ,
OMOCM1 , OMJOBN , OMOCM2, OMUPMJ , OMOCM3 , OMUPMT , OMOCMA ,
OMOCMB , OMOCMC, OMOCMDSC
from f986101
where OMENHV='PY7333' and OMSTSO='AV'

GO

Then the environment was more or less set, but had no tables. So I created the new tables like this:
- I had to make one slight change in the F9860 table-- the COPY DATA (SICPYD) for F0101 was set to "Y". This controls whether the data is copied for this table or not. I didn't want it to copy this data, so I set it to no:
update f9860 set sicpyd='N' where siobnm='F0101' and sifuno='TBLE'

- Then, from Batch Versions, I ran the R98403. I made a copy of the XJDE0021 version, then modified its processing options to reflect the Business Data - NEW data source as the target and Business Data - CRP as the source. BE CAREFUL here, if you get these backwards you will overwrite tables in the good data source!

I specified that production data should be loaded instead of test data. This loads nothing to most tables. It does load tables with SICPYD set to "Y" in F9860 (that's why I had to do that last step.

I also modified the data selection to specify just one table for a test-- F0101. I did this partially to make sure no data was transferred, but that the structure was correct.

- I ran the new version of the R98403 in LOCAL. It worked, creating the F0101 table in Business Data - NEW with no data.
- I modified the new version of R98403 again, removing all the data selection. Then I ran it again. It took about an hour. It created all the tables from the Business Data - CRP data source in Business Data - NEW.
- There were some errors for tables which I did not have the specifications for (about 8 of these, all things we had developed). So I went to the OCM in PY7333 and did GETs from the Exit bar on each of these tables. Then I modied the R98403 version to only get the tables I was unable to get before. I ran this version again, and it worked.

The Environment was now complete.

Now I had to fix it so users could actually use the new environment.
- In User Profiles (P0092|ZJDE0001) I changed the allowed environment for our user group to allow the new environment. This is where I was very happy that I had previously put our users in groups, because I only had to make the change in three places.

- I created a new update package based on my full package for the PY7333 path code with no objects, but one feature: the ODBC data source for NEW_CRP. I distributed this the distribution group for the users of the new environment.

That was all! The new users had to accept the package, then they were able to enter the new environment. The process was fairly simple, and except for the OCM mappings for the server map, almost nothing unexpected happened.

Hope that helps someone.
 
Tim,

just wanted you to know how much I appreciate your posting this type of stuff here on the forum. Even (especially) if others chime in with corrections or additions the thread just becomes that much more valuable.

Keep up the good work!

Cheers,
 
Would you not also need to make the changes to OneWorld (New Data source, Environment etc) to the PLANNER pathcode on the deployment server as well????
 
Hi Tim

Because we are going to implemente PY7333 and have key in all the master data(address,item...).
We are trying to make a scenario just like what you described in your post.
Another PY7333 Environment to test what we have configurated in real PY7333.

Thank you very much for the information you have post.
I have refered to "OTI-01-0056" in KG,"Creating a Custom Path Code and Environment that can be upgraded or updated".
This document describes how to create a custom path and environment that can be upgradded or updated by ESUs.
But it seems not what we are looking for.

We will try to follow the steps you have mentioned.
Hope we can do it successfully~~

JackyLai
 
Back
Top