Tuesday, May 8, 2012

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.

Tuesday, March 6, 2012

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.






Tuesday, February 14, 2012

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!

Wednesday, November 16, 2011

What's up with Vi

Continuing with my last few posts on basics of Unix world that a CNC needs from time to time, today I chose to talk about the Vi editor. Its one of the most powerful editors on the console and certainly must know aspect of CNC administration.

Here are the few commands i know and have used over the years in Vi extensively. If you don't get it straight away just practice with patience and you will be rolling in no time

If you do not want to go the full path straight away just concentrate on the "basicest"  operations of creating, navigating , inserting and deleting in a Vi editor and you will be good for a while!! :)


General Startup
To use vi: vi filename
To exit vi and save changes: ZZ   or  :wq
To exit vi without saving changes: :q!
To enter vi command mode: [esc]

Counts
        A number preceding any vi command tells vi to repeat
that command that many times.


Cursor Movement

h       move left (backspace)

j       move down

k       move up

l       move right (spacebar)

[return]   move to the beginning of the next line

$       last column on the current line

0       move cursor to the first column on the
current line

^       move cursor to first nonblank column on the
current line

w       move to the beginning of the next word or
punctuation mark

W       move past the next space

b       move to the beginning of the previous word
or punctuation mark

B       move to the beginning of the previous word,
ignores punctuation

        e       end of next word or punctuation mark

        E       end of next word, ignoring punctuation

        H       move cursor to the top of the screen

        M       move cursor to the middle of the screen

        L       move cursor to the bottom of the screen


Screen Movement

       G        move to the last line in the file

       xG       move to line x

       z+       move current line to top of screen

       z        move current line to the middle of screen

       z-       move current line to the bottom of screen

       ^F       move forward one screen

       ^B       move backward one line

       ^D       move forward one half screen

       ^U       move backward one half screen

       ^R       redraw screen
( does not work with VT100 type terminals )

       ^L       redraw screen
( does not work with Televideo terminals )


Inserting

       r        replace character under cursor with next
character typed

       R        keep replacing character until [esc] is hit

       i        insert before cursor

       a        append after cursor

       A        append at end of line

       O        open line above cursor and enter append mode


Deleting

x       delete character under cursor

dd      delete line under cursor

        dw      delete word under cursor

        db      delete word before cursor


Copying Code

        yy      (yank)'copies' line which may then be put by
the p(put) command. Precede with a count for
multiple lines.


Put Command
        brings back previous deletion or yank of lines,
words, or characters

        P       bring back before cursor

        p       bring back after cursor

Find Commands

?       finds a word going backwards

/       finds a word going forwards

        f       finds a character on the line under the
cursor going forward

        F       finds a character on the line under the
cursor going backwards

        t       find a character on the current line going
forward and stop one character before it

T       find a character on the current line going
backward and stop one character before it

; repeat last f, F, t, T


Miscellaneous Commands

. repeat last command

u undoes last command issued

U undoes all commands on one line

xp deletes first character and inserts after
second (swap)

J join current line with the next line

^G display current line number

% if at one parenthesis, will jump to its mate

mx mark current line with character x

'x find line marked with character x

NOTE: Marks are internal and not written to the file.


Line Editor Mode
Any commands form the line editor ex can be issued
upon entering line mode.

To enter: type ':'

To exit: press[return] or [esc]


MOVING

:# move to line #

:$ move to last line of file







Thursday, November 10, 2011

Lets talk .profile

The .profile file in a Unix environment is a "know all" file. It resides under the /home/<userid> dir of the os and it's the first one to be executed whenever that particular user logs in. This is the file that creates the environment for the user and has all the shell options and environment variables defined.

Before we go into how JDE uses this file and why is it important for it, lets see what all it has first:

First and foremost comes PATH:

As the name suggests this is where the path to the dirs of the installed software go. Lets suppose we have a Unix user account MaxPayne. If MaxPayne has all the paths to the software or commands he uses defined in the .profile , he can run those command from anywhere once he logs in to the Unix shell.

Then comes the Editor.

More often than not, when we talk about default shell its the BASH shell and MaxPayne is no different. His shell is bash too and his .profile has Vi as an editor. Vi Editor is one of the most powerful command line editors that we have. Refer my post for the details about using Vi. If you need to change your editor all you need to do is specify it here in the .profile. For the record MaxPayne loves Vi.

Now we see PS1

PS1 defines what the command prompt looks like in the shell. Typically you will find the server name at the command prompt. But MaxPayne is smarter, he has included the $PWD in the PS1 definition so that he can see which dir he is in without ever needing to run pswd again!!

Last common entry is the Alias

Aliases are used to rename some commonly used commands. For example alias dir=ls will help a confused windows user to get the directory information he needs. Aliasing dir with ls tell the unix system to run ls every time MaxPayne types dir.

All the above are default entries in the .profile of any user. When it comes to a JDE Enterprise server what we see are the Oracle homes and the oneworld homes defined in the .profile. When the platform pack is run in the system it creates a .oneworld file in the user dir. This file tells the jde processes where all the JDE files are. We load this .oneworld in the .profile of the JDE file owner. Unless this is done services will not be able to start. So now when you see load libraries failing or path related issues coming up on restart, you know where to check. Majority of the times a corrupted .profile is the source of this.

This in brief is what .profile means to the JDE CNC. If you need any help configuring yours feel free to drop me a comment.









Wednesday, November 9, 2011

Let’s Mount …..

When i was introduced t0 JDE the first and foremost thing that motivated me to go for becoming a CNC expert was that it gave me opportunity to work on UNIX.  Its beyond doubt one of the most formidable platforms for any business and i was a lover since my early college days :)

One of the biggest differentiating factors in Unix is its file system handling. People coming from the Windows world find it difficult to understand that the file storage has nothing to do with the  drives they see in the explorer but is actually a mounted space allocated from the memory available.  Its this “mounting” that makes any file system available for storage.

Syntax for Mount command is as follows:

$ mount /dev/hda3  /home

This command will “load” the resource or filesystem in disk drive hda3 into the local /home and then /home will have the memory on hda3 for use.

The best part of Mount is that you can not only mount hard drives connected to your server but use ones that are connected to the network as well.  This is what is meant when some one says “the db client is a NAS mount”!!

Remember that there is no registry to be maintained in Unix and we don’t necessarily have to install an application on a particular machine to use it. It’s all about the Environment Variable and the file locations.  So if you have an executable and the right parameters set for it in the environment variable, the executable knows how to take care of itself. It knows exactly where to look for the files it needs to execute.

Now when anyone says that the “db client is a NAS mount”, you can figure out that the DB client is installed on a different machine in the network and that particular drive is mounted in your Enterprise server and the Environment variables on your JDE Enterprise Server are set such that your  server knows where to look for the DB client files when its trying to connect to the DB. As far as both the servers concerned are in the same domain and can reach each other in quick time, this works seamlessly.

The biggest advantage that this brings is maintenance of the supporting Applications. If the company has several hundreds of databases this architecture helps the DB support group to maintain all the db’s on their own servers and all the app teams can just mount the locations. Patching and maintenance is spared of the fragmentation and the upgrades can be handled much more efficiently.

If you want to check all the mount points that are currently there on your server execute the following command:  more /etc/auto_direct

Have fun!!

Let me know if the post gives you a little bit of an insight on Mount as a UNIX feature. You can always check the man pages for details about any UNIX command. My intention over here was to drive away the initial fear of “what’s this!!” from anyone who is new to the world of Unix & CNC admin.

JDE CNC Interview Questions

If you landed up on this page searching for “JDE CNC interview questions”, you are at the right place. Read along to find what they ask, what they intend to ask, what they thought they were asking, what they cannot ask and how you should answer, what you should say in case you can’t answer or should you at all be interviewing for a CNC job and yes, you can thank me later.

The first thing that you should do is to stop searching for the interview questions and believe in the fact that there is no shortcut available to portray yourself as an excellent CNC. It’s not a set of instructions that you should know or a bunch of APIs you should know how to call and refer back to. It’s not the “do one time and forget it was ever coded” type of a job. You just cannot read a few pages and get into a CNC’s pinching shoes. No you can’t!!

CNC is a fire fight. It’s a trek through thorny bushes with a low quality slipper on in half pants on a dark night, may I add, without a torch. No, I am not over exaggerating a wee bit. Tell me if you can wake up in the wee hours of the night after you have had a three quarters of a large pizza and a couple of beer bottles to trouble shoot a failed package build or a hung UBE. Or get interrupted on a date for a question regarding why a UBE runs slow from citrix but fast from office. I don’t see any one nodding in affirmation. Yes, this is just a glimpse of a CNC’s work.

A CNC’s job requires a different attitude and a keen eye. It needs a person who loves technology to the extreme and is not bothered to hear complaints about it day in and day out. In fact, any complaints regarding a system to him, is an opportunity to sell an upgrade, a need to get more people involved. A CNC has to be a social butterfly and should be able to convince anybody and everybody that he is in control even in face of a catastrophe. He should know the system inside out rather than outside inwards.

So if you are asked to tell about package build, don’t act like it’s just a job that the dumb guy does at a developer’s command every now and then in your project. Rather be prepared with what’s an err file and how and when does the sts gets created. Know your F91300 when talking about schedulers and remember to talk about platform independence when trying to explain what’s so special about JDEdwards. If you are among the ones who cannot tell what’s the security type of a JDEdwards setup when the security server is not running, CNC is not for you. You just cannot handle the curve balls a CNC job throws at you if you have a unidirectional knowledge. Rather than looking for specific questions and answers invest your time in learning the system more. Learn to appreciate the technology within. Once you have enough respect for the system, you can go for any interview that a CNC job asks for. You will be ready for it.

Please remember that the views expressed are solely my own and I do not guarantee any success. But yes at least if you read this before posting for the quintessential “JDE CNC interview questions” in any JDEdwards forum, it will surely save you from some blushes.

If any CNC gurus land up here, please feel free to leave me a comment. And help me describe the job we all love (no I am not being sarcastic) with better examples than mine.

To all the budding CNC’s , good luck !!