jd-edwards

10 Things You Should Know About Packages in JDE

1. A package defines and contains components to deploy

Packages are nothing but a source to provide the users with the latest information. This may include the latest copy of few modified objects or it may be an entire full package which contains everything that an user requires during the initial installation of workstation. A package may contains applications, objects, business functions etc. A package may be deployed to workstations, web servers and enterprise servers.

2. There are 6 types of packages

  • Full client package
  • Update client package
  • Full server package
  • Update server package
  • Full mobile package
  • Update mobile package

I have worked with the starting four types. To describe them in short, full client package basically contains everything that is necessary for a developer to run and develop in JDE. They contain central objects for a particular path code which is defined while building the package. Update client packages contain the new copy of objects which replaces the existing copy of those objects on that particular workstation. Thus when there is a software change or something similar, you can deploy those changes on each client workstation by deploying update client packages. Full server package is similar to full client package except that it doesn’t contain client specific BSFNs, local data and features. Update server packages contain new copy of objects that are supposed to be replaced on the server. An update server package can be deployed if and only if it has a parent package which is deployed and is live. It can contain only those objects which are already present in the parent package, thus it just replace them once it is deployed.

3. Mandatory and Optional Packages

As discussed above, a package may be deployed to different workstations, groups, enterprise servers etc. Now there are some changes which are supposed to be installed mandatorily while others are optional. As packages are used to deploy these changes, they also follow the same rule. Thus there are two kinds of packages, mandatory and optional. When mandatory changes are supposed to be deployed, a package is marked as mandatory while when you wish to leave it up to user whether or not to accept a particular change, you can set the package as optional. JDE cannot be accessed by a particular user if he/she refuses to accept a mandatory package.

4. Fastpaths

Some important fasthpaths that you can use :

  • Package Assembly – P9601
  • Package Build – P9621
  • Package Deployment – P9631
  • Package and Deployment Tools – GH9083
  • Object Management Workbench – OMW
  • Object Management Configuration – OMC

5. Package Flow : Assembly -> Build -> Deployment

It is important to understand the flow when talking about packages. Packages are first assembled, then built and deployed.  After assembling a package with Package Assembly Director, you need to build the package. Now you must understand what happens when you build a package. We already know that package contains the components that are supposed to be deployed. Now these components are nothing but certain set of files which are supposed to be copied from one location to other. Packages follow a certain hierarchy of folders. When we build a package, automatically the folder hierarchy is created and then populated with the files. The location of this package folder depends on the path code selected during build. Files in the source and include folders are obtained from a certain path. This path is based on the path code and it is obtained from the deployment server. Central objects are used to populate the reamining directories. The bin32, lib32 and obj folders are populated with business function build process. After a package is built it is deployed on the enterprise server or workstation, depending on the type of package.

6. Package Assembly and Build

I have already discussed the package build process in above point. This one is to inform you about various things you can do while building a package. While defining a package build, you are presented with 2 options :

  1. Director : Allows you to configure the package build.
  2. Express : Allows you to directly build using default options.

While selecting package build location, you are provided with 2 options :

  1. Client : Check this if you wish to install package on a workstation.
  2. Server : Check this if you wish to install package on a server(s).

You can set the compression options for a package only if you are using compression. To check whether you have compression enabled check your jde.ini file. It is located at C:/Windows/jde.ini for windows workstation. If the “DoCompression” equals to 1. If it is not set to 1 then Compression is not enabled for your JDE and you wont see the Compression options while building package.

Once you have built the package, you need to submit the build. To submit the build, you need to select the particular package in Package Build Director application. Confirm that its status is Build Complete. If its status is In Definition then you need to Activate it by clicking the Active/Inactive button under Row Menu. Once done, Submit Build by clicking Submit Build button under Row Menu. You will be prompted to select the output option. “On Screen” or “To Printer”, Select On Screen to view the PDF after the build is completed or To printer to print the respective output.

7. Package Deployment

Once the package is assembled, built and the build is submitted, you can use the Package Deployment Director application to schedule the deployment of that package. Select the package in Package Build director and click Deployment under Row Menu. You will be provided with different server options. Choose the appropriate server type based on what kind of package you have built and proceed. Select the appropriate server names to which the package must be deployed and proceed. Finally expand the respective server type to find the servers scheduled for deployment and click on deploy. If you want to deploy packages on 1 server at a time, then select the individual server and click on Deploy. Once the deployment is done, you will be provided with a pdf with the output results. If your deployment failed make sure the port numbers and servers were correct while building the package. Also check the jde.ini settings so that they are in sync with the server settings.

8. Build Revisions

Sometimes it may happen that you wish to change the build options of a package which is already built. You need to use Build Revisions form for the same. Before you use Build Revision, make sure you inactivate the package. To inactivate the package, select the package under Pacakge Build Definition Director and click on Active/Inactive package under Row Menu. Verify that it is inactivated by checking its status under Properties. Then click on Build Revision and proceed to change the respective options.

9. Object Management Workbench

Though not directly related with packages, OMW is quite an important application when it comes to objects and projects. OMW can be used to perform a lot many tasks but I wont be discussing them here, we shall stick to the ones that are indirectly related to packages. Now, we know that objects may belong to one or more projects and may be of various types such as business views, business functions, tables, workflows etc. To change the status of the project, you should use OMW. Find a particular project which you wish to promote/demote by using Advance Search under Form Menu in OMW. Select the project and change its status. You will first need to be an owner of that project. To do that select the project, and in the search tab, select Owners > User ID. Search for your username and click the “<-” button to add the user to the project. Now change the status of the project. Whether or not you can change the project status depends on the activity rules defined for that particular status. Read the below point to learn how to check activity rules.

10. Object Management Configuration

This point is in continuation to the above one. We shall discuss the activity rules management using OMC here. Now to check the activity rules, open JDE Solution Explorer and type OMC in fastpath and hit enter. Click on Activity Rules. Fill the “From Project Status” with the status you wish to check, say 21 (Programming). If you just wish to browse around fill “*” in From Project Status and do a “Find” by clicking on Find button in navigation bar. Once you do a find, you will see a folder like structure of status. Click on it and Hit Select.

You will see a grid with certain column headers such as Active, User/Role, To Project Status and Description.

The headers are self explanatory. Just fill in 1 under Active, your user ID or role under User/Role and the status under To project status. Click Ok to confirm changes. Now you can promote/demote a particular project at that status from the status for which you just defined activity rule. The advanatage of activity rules is that you can restrict and allow certain group of people from promoting and demoting projects. Generally activity rules are not defined for particular users (as there are lot of users in JDE and it is impossible to assign rules at individual level and keep track of them). So we prefer to add rules for roles instead.

 

That’s all from my side. If you wish to read more about packages and JDE refer to Oracle Docs. There are quite a few resources available. Here are some for your use :

JDE Enterprise Tools РPackage Management Guide (PDF)

Online Documentation :

Assembling Packages

Understanding the Package Build Process

Building Packages

Deploying Packages

You can navigate around the online documentation to find out more about objects and other package related contents. Hope this cleared your concepts about packages in JDE. If you have any doubts or wish to add your input to this article, feel free to post a comment below.

Leave a Reply

Your email address will not be published. Required fields are marked *