JDE Package Build: Pro Tip

Build your Production Full Packages on QA or Dev Enterprise Server ------- Yes you read that right! And no I am not smoking anything suspicious.

Seriously, there are more than one benefits of doing this. Before I actually go ahead and enlist the benefits, lets take a look as to how we can set this up. You now know that all you need to do for JDE system to recognize a server or machine is to update in a certain table somewhere. This will be no different! Lets see what all tables we need out here.

When we assemble a package , we select the server we want to build the package on based on the entries in F98611 (DataSource Master) Table. So that's where we need to change. Now, we have two DataSource Master Tables, one in the Server Map and one in the System data source. Here we will do the changes in F98611 in the System DataSource because thats where my System looks into for the server info.

If you have the same "SYSXXX" the entry for all your enterprise servers should already exist there and you will not need to configure anything separately. But if your SYSXXX for production is separate you will need to insert the QA server name in the table. This is what you will need to insert in the SYSXXX.F98611 table:

insert into sysXXX.f98611
select omenhv, 'NEWSERVERNAME' omdatp, 'newservername' omsrvr, omdatb, omoown, omdllname, omll, omlib, omomui, omomto, omomds, omomjd, omomcc, omdstp, ompid, omdatuse, omuser, omocm1, omjobn, omocm2, omupmj, omocm3, omupmt, omocma, omocmb, omocmc, omocmdsc from sysXXX.f98611
where omdatp ='NEWSERVERNAME' and omsrvr = 'newservername'

Insert, commit and restart your EOne services for the changes to take effect. Unless you restart the services the entry will not show up on the Server Selection Screen in the Package Assembly application. No points guessing why we need to bounce the services for the entry to show up in that table: Its a bootstrap table.

Now you can select your QA server when you are building a PD full package and the build happily runs on the QA Enterprise server. Yaay!

But wait! What happens after the build completes. You can not deploy a package built on the QA server onto the PD enterprise server, Can you?

Of course, not!! But there is something else we can do. Go onto your Deployment server, under the PACKAGE\packagename dir you will have a folder by the name of the Operating system of your PD enterprise server. Inside this you will have a "enterpriseservername.inf" file. Go ahead and open it.

It will look somewhat like this:

[SERVER PACKAGE]
PackageName=PD7334FQ
Type=FULL
Platform=SUN5.10Generic_139555-08
BuildMachine=qaentsrvr
BuildPort=6010
SPEC=1
SpecList=0 , 1 , 10 , 13 , 14 , 15 , 16 , 17 , 18 , 2 ,
BSFN=1
CAEC=1
CALLBSFN=1
CBUSPART=1
CCONVERT=1

You will need to update the name of the file to "pdentservr.INF" and change the BuidMachine to pdentsrvr. Save and exit.
There may be a case where you are running two different versions of OS on you enterprise servers. If that be the case, you will need to update the Platform accordingly. SSH into your PD enterprise server and run "uname - a " to get the OS name and just update it in the inf. This takes care of the client part of the build. Fun is at the server part.

For a package to be deployed the package has to exist in the /jdedwardsoneworld/exxx/packages dir of your enterprise server. Now, that we have build the package on the QA Enterprise server we need to send it over to this dir on the PD Enterprise Server. Make sure you have "sftp" enabled between the two servers and libraries for "tar" utility are installed on both of them. Here's how you transfer your package beween QA and PD Enterprise servers:

1. ssh into your qa ent server
2. go into the /apps/jdedwardsoneworl/packages dir using cd command
3. run this tar -cvf  temppkg pdpackagename
4. this creates a zip file called temppkg for your full package "pdpackagename"
5. sftp pdentsrvr
6. login with your passwd... its mandatory that you have the same userid owning all the jde files and folders on the two servers.
7. go into the /apps/jdedwardsoneworl/packages dir using cd command
8. run this ... put temppkg
9. Once the copy completes login to your pd ent server
10. go into the /apps/jdedwardsoneworl/packages dir using cd command
11. run this... tar -xvf temppkg
12. Voila .... you have your pdpackagename dir in the /apps/jdedwardsoneworl/packages dir

Now your pd package is ready for deployment. Oh my goodness!! So much effort just for Package build and deployment!!

Well, a lot of this is just one time setup.And it sure has a lot of advantages. Its time we see what they actually are. Here you go:

• You can run a PD build during business hours. No night outs!!<Happy CNC>
• Ube's running on the PD ent server will not affect the speed of build. <Happy CNC>
• Scheduler server can continue to run while the build is ON and you can just stop it when you want to deploy the package <Happy Suits>
• Your setup complies to the SOX control which abolishes installation of compilers on Production machines. <Happy Suits>

So two reasons to get a Happy CNC and two for the Suits, I say there can never be a more Win Win in a single act!!

Jokes apart, compilers on production servers are indeed frowned upon in the SOX parlance and there exists a way where we can avoid this completely in JDE. This also helps if you need to trouble shoot a build for anyreason, it can be done whenever needed with no affect to the business whatsoever.

I know this has become one long post and you may have questions about the approach. Well that's why whe have the comment section there. Feel free to ask away....


Jd Edwards by Donatienne Ruby, Christabel [Paperback]

Find us on Google+

Enterprise Server Migration: UNIX

In my opinion after Package builds, Server Migrations are the real staple food for a JDEdwards CNC consultant. The constant changes in OS technologies and the ever expiring hardware support contracts ensure that we do at least a couple of such migrations in a financial year. If your setup is configured for high availability then you get to do it more often than you would like.

I still remember as a young trainee getting a grasp of this was a nightmare. I have an unexplained fear of the Typical Installation Plan (P98240) application and the white space that it shows. Grids do not scare me as much as that particular white space. All the mumbling rumblings of creating and add on plan, adding the new enterprise server and then removing the old one went over my head in those days as a trainee. But I did one thing well, nodded my head as though I understood every last word of my trainer and sailed through the training. I am more of a guy who knows that if he is drowning he can swim but just wont do it for leisure in a swimming pool. I got to have the waves to challenge me.

Finally when I got to do my first real Unix Enterprise Server Migration at a client's place i dug deep. I dug so deep that I landed at the tables that govern them all. It all started making sense and i have done 9 such migrations this far. Lets talk about the tables that we should be looking at:

• SYSXXX.F98611 : DataSource Master Table
• SYSXXX.F986101: Object Configuration Master Table
• SYSXXX.F91300: Schedule Job Master Table
• SYSXXX.F9650: Machine Master Table
• SYSXXX.F9651: Machine Detail Table
• SVMXXX.F98611: Data Source Master (Server Map DataSource)
• SVMXXX.F986101: Object Configuration Master (Server Map DataSource)

Here SYSXXX stands for the Sys schema in the database that has all the tables that fall under the "System - ProductVersion " data source. For instance System - 812 will have a SYS812 schema and System - B7334 will have a SYS7334 schema. Similarly there will be a SVM7334 schema for 'EnterpriseServerName - B7334 Server Map" data source.

If you just change the old server name to new server name in the above tables your migration is half done. Here's a sample Update query that can be run to update the same in say SYSXXX.F98611.

Update SYSXXX.F98611 set omsrvr = 'newserver' where omsrvr = 'oldserver';

 All you need to do is get the old server name and replace it with the new one, matching case to case.To get the entire list of updates that you should make, you can just go to the tables I specified and pick the values that you need to change. Once you get all the values it should be fairly easy chalking all the update statements out.  Be very careful with the case of the name, specially in Unix



The next step is fairly simple. Once you get the new server ready, make sure you have "rsync" command working on the new server. Make sure you have the same user id configured on this new box. Once you are able to login to the new box with the same id, follow the following steps.

• Copy and paste your .profile from the old server to the new server
• Make sure you can reach your database from the new server. If you have NAS mounts for the database clients make sure they are connecting properly
• Check the "cc" libraries if they are consistent with those on the old server. Make sure the version is in the MTR.
• Run "Rsync" to sync up the base "\jdedwardsoneworld" directory on the new server with the old server. Here's the syntax of typical rsync run:      rsync -avz --rsync-path=/usr/local/bin/rsync /apps/jdedwardsoneworld/* jdeuser@newservername:/apps/jdedwardsoneworld
• Update the JDE.INI to reflect the newservername as the security server. Do this step only if you know that the old server was a security server.
• Run ./RunOneWorld.sh and you should be delighted and dancing by now.
• Before you get too excited run the porttest and check the output. 

So this is how I do my Server Migrations. I find it fairly easy to control and it keeps me away from the Installation Plan. Rather than executing something which I don't know the details of I am much more comfortable changing value and controlling my destiny!!