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!!

Configure JDE Development on Citrix

The Citrix platform provides an easy base for setting up development machines to support development in JDE from offshore. The fundamental logic behind setting development on Citrix is that all the users/developers accessing the environment will have a independent Pathcode created.

Since the default directory for a user resides under C:\Documents and Settings there is a need of changing the default user path. Incase of a shared citrix server it becomes mandatory that a new variable be defined at the system level which can then be used to define the default user path. In the script below the variable
%userpath% is the system variable which maps the user to D:\Users. This is also a good practice because the citrix login will copy the Pathcode over for each user hence mapping it to D: drive will save a lot of space on the System drive C:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@echo off
net use J: /del.
net use J: \\deploymentserver\b7334
if exist %userpath%\%username%\b7\system\bin32\activConsole.exe goto startow
mkdir %userpath%\%username%
@echo Copying standard OneWorld Development Client to your profile...
@echo Please be patient - this takes up to 20 minutes and only occurs
@echo on the first use.....
mkdir %userpath%\%username%\b7
echo Copying authorization files.....
xcopy d:\b7\*.* %userpath%\%username%\b7\*.* /s /e /d /h /y
:startow
copy c:\windows\jde.ini %userpath%\%username%\windows\jde.ini /Y
@echo Starting Oneworld....
start %userpath%\%username%\b7\system\bin32\activConsole.exe
:end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Save the script as ExecuteJde.bat and publish it via Citrix. The first time a developer executes it from the farm, it creates a B7 dir for the dev's login it under D:\Users and that becomes the patch code the dev uses every time he logs in.

In case of full package builds, just make sure all the local packages are deleted before the full package is installed on the system.

It is preferred that the users have a local profile as opposed to the roaming profile.

Sizing: JAS performance and DOM

Client work stations play a huge role in the performance benchmarking of any JAS architecture! This statement befuddles many people who view JAS as a sole entity entirely dependent upon the web server and the available bandwidth for performance. If type of processor on the client machine is mentioned in the recommendations list, there's a reason for it !!

Document object Model or DOM has a huge role to play in the working of EnterpriseOne JAS. DOM is a set of conventions for interacting with the objects in the HTML, XHTML or XML documents.  DOM presents HTML document as a tree structure. Objects in this tree can be accessed and manipulated using methods on them as specified in the DOM APIs.

Now, EnterpriseOne heavily relied on DOM objects for its functioning. The grids, for example, are stored as DOM elements on the client PC. These elements are processed and rendered by Java Script running on this client PC. So the entire time required to fetch data into a grid is spent on the local machine in processing these DOM elements rather than on the Web Server. Clearly larger the number of columns in the grid larger will be the number of DOM elements and hence greater will be the time to fetch, So now, if the grid columns are fixed and the database type is constant, its clear that a dual core pc will take far less time as opposed to a single core one in fetching records in a grid.

This is the main reason of recommending a level of hardware architecture for the local workstations when sizing for a new EOne implementation.

TAM Spec and XML Spec : Musings

Spec is short for Specification, which together with the C components form the Central Objects in EnterpriseOne.

Format in which spec is stored saw a change after E1 8.12. Pre 8.12, specs were stored in the TAM format and now we have the XML format.

TAM or Table Access Management was a proprietary format of storing the details of the object specifications. The package build process would build separate TAM files for each central object table (.ddb and.xdb files). This will then have to be generated using enegerator on dedicated machines to get the java code that ran on the html server.

Once XML specs were introduced from e1 8.12 onwards, these specs could be generated 'On Demand' by the web server. The specs got stored in databases instead of TAM files. The build now creates a DBMS table for each spec file. For the client packages these tables get stored in the local databases on the Deployment server and the client workstation whereas for the server packages they get stored in the relational database of the E1 system.

One specialty of these spec tables is that they do not belong to the OL datasources and hence can not be queried from the E1 side. They can however be viewed by using the utilities like the Enterprise manager from the DB side.

With the change in spec types a new feature that came in is that now the client spec and server spec are identical in the system. Previously FDASPEC, FDATEXT and SMTTMPL did not use to get copied to the enterprise server during the package build but now they are.

Here's hoping some doubts about the two buzz words in E1 got clarified for readers of EOneDuniya!