Auditing JDE: Column for Scheduler Server Status

In JDE the scheduler server is identified by the control record in the SYSXXX.F91300 table with a *SCHEDULER value in its SJSCHJBMN column.

The status of the scheduler server, as in, its active or inactive status, is represented in the SJSCHCTCD01 column.

 SJSCHCTCD01 has 000 if the scheduler server is down.

It can have the following values if the server is up and running:

111 - neither the job launcher nor the job monitor is paused

011 - the job launcher is paused but the job monitor is not paused

101 - the job launcher is not paused but the job monitor is paused

001 - both the job launcher and the job monitor are paused

Object Transfer between Disconnected Instances

At various occassions we come up with a requirement where we need to send pobjects built on one instance to another instance at a remote location. Product packaging is one way of dealing with it.

Lets try and install objects created in one JDE instance on a separate JDE instance of E812 bypassing the Product Packaging technique.

 To make things clear, lets say we have one instance of JDE running at a consulting company in USA. Let their Deployment Server be DEPUSA. They need to send some objects in a project to a client in Canada. The client's deployment server is DEPCANADA and their instance is completely independent of the consulting company's instance. Now lets transfer opjects from USA to CANADA.

I ) On Source JDE Installation:

1.    Make a list of all objects that have to be deployed on Target JDE installation.

2.    Check in all the objects from development workstation to the server.

3.    Go to Menu GH9083 (Package Development Tools), take option “Package Assembly” (P9601) and follow the Director. Select all the objects that are to be deployed on   target machine. Make sure that the following instructions are followed while package assembly :
a)    Package type should be an  ‘Update Package’.
d)    Parent package should be a ‘Full Package’.
c)    Check the option ‘Include Object specification’.
d)    The ‘Path code’ and ‘Parent Package’, which you are specifying, should      exist on target JDE.
e)    Activate the Update Package before taking the Define Build option.

5. Take Option Package Build (P9621) and follow the Director. Select the package that you have assembled in the above steps to be built as above and make sure that the package is built for  Client Workstation only. Check in Build Specifications options.  If you have a Business Function in your Package, check in Build Function Option. 

6. Activate the  Package and submit the  Package for Build Process .

7.    Verify the report generated after Build Process is completed .If any errors are reported take option Package Build History (P9622) and verify the Logs, Status  of the Package. Then take option Submit Rebuild from this screen if any errors are reported for that Package. Make sure that the Package and All Objects of the Package are built successfully. 

8    The Package build process creates PackageName.INF file in the directory \\Servername\E812\PACKAGE_INF (Ex: \\DEPUSA\E812\PACKAGE_INF) and also a PackageName Directory in \\Servername\E812\Pathcode\PACKAGE directory  (Ex:  \\DEPUSA\E812\ProdE812\PACKAGE)

 9.  Copy the above PackageName.INF file and PackageName directory on a CD or any other portable media. This is now ready to transfer to the Target JDE  Installation.    
 
II) On Target JDE Installation


1    Go to Menu GH9083 (Package Development Tools), take option “Package Assembly” (P9601) and follow the Director similar as you did in STEP-I .Do not select any Objects for the Package to build i.e., Assemble an empty Update Package with the same name as given in STEP-I . The Path code, Parent Package should be the same as given in while assembling an Update package on source JDE installation.

2.    Activate the assembled Package before taking the Define Build option.

3    Take Option Package Build (P9621) and follow the Director. Select the package that you have assembled in the above steps to be built as above and make sure that the package is built for  Client Workstation only.

4.   Activate the package before taking the Define Build option

5.    Check the report for any errors. Ensure that the package is built successfully.

6.    Similar to STEP-I the Package build process creates PackageName.INF file in the directory \\Servername\E812\PACKAGE_INF  and also a PackageName  Directory in \\Servername\E812\Pathcode\PACKAGE directory .

7.    Replace the PackageName.INF and PackageName directory created in this step with those created in earlier step.

8.    Now open the file PackageName.INF in edit mode and change the source Severname wherever you find in the file to the target Servername.

9.    Now select a development workstation in the network and create OL entries for all the new objects, which you are going to deploy. If the objects are existing objects checkout  the objects to the workstation.

10.    Deploy the Package to the development workstation.

11.    Open all the objects in the design mode, check whether the specifications are transferred are not. Compile all the objects and check in the objects in to the server.
 

Done! Your objects have reached the target server :)

JDE Scheduler: Delete Jobs

One of the most common questions asked in JDE forums is why can't we delete jobs from the JDE Scheduler? There is a delete button out there that only throws an error message when pressed!

Well things are not always as simple as they look. And if they were, we poor CNC blokes would have appeared less crazy than we do :)

Here's what actually happens. Each Scheduler job has two records that are stored in the header (F91300) and the details (F91320) tables. So when you try and delete a job from the header, you run the risk of leaving a detail records that has no header and can never be launched. So JDE prevents this from happening by throwing the error message that you get, when you try and delete a Scheduled job from the P91300 application directly.

The correct way to delete these jobs is to run R91300B and then delete the records using P91300. R91300B does not clear the header to leave the audit trail. If you want to clear them, feel free to clear using the application.

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.

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.