• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Website for JDE Package requests from developers

Dear All,

I would like to know if anyone had created a Website for JDE Package requests from developers, if so then please share the page design and code.
I want to implement the same.

What I am looking for is a website which developers can use for requesting for packages for DV, PD etc, once the project name & promotion path code is given then it should come to CNC and once CNC is done with package then he should update the website with completed.

Thanks in Advance.


Legendary Poster
Having the right OMW Configuration Activity Code is also important. For example, you could have "22" as "ready for a DV Package" - and every evening at 6pm, the CNC searches all projects at status code 22, and builds them. Same with "24" for "ready for promotion from DV to PY " and "28" for "ready for PY to PD promotion and package"....if everyone is on the same page as far as the OMW activity rules are concerned, then you don't even need communication - OMW does it for you !!!


VIP Member
I am with Jon here , why over engineer a solution , when the OMW status feature can be used to manage package build requests.

I have several customers using this very effectively. Developers move the project to a specific status once they are ready for DV build , CNC moves to a completion status once they have finished build and deployment. So on and so forth for DV to PY, PY to PD etc. You can also use the OMW project roles along with row security to make sure that only specific OMW project roles may say for example move a project to a status that is to request a move to Production.

You can also use the OMW project Attachments screen to note any special instructions for the projects for things like table or index generations.

What's even better , everything is logged by the default OMW logging features , so you have complete tractability also.

The only flip side of all this , is that you have to be on a FAT client to use OMW. But with tools 9.2 and the web based OMW for User Defined Object types , something like just status change which will not invoke any transfer activity rules may actually work for projects containing OL objects too ( I will try this out in a day or two when I get some time) , so that may not be a problem once you get to tools 9.2.

David Robertson

Reputable Poster
You can also have the rules for promotion to 22 etc send an email to CNC to say that the project has been promoted ready to build, so you don't even need to check manually each day, and could in fact do multiple package requests per day as required.


Active Member
Here's an easy solution: Build a SQL scheduled job (or a UBE) that runs once per day, listing all of the OMW Projects that have any "interesting" status.

Have it automatically email your CNC, your developers and any interested JDE Power Users.

Then everyone will receive a list of all packages that are waiting to be built, all packages that are going into production, etc.

At that point, your developers don't even need to leave OMW. They just set their OMW Project Status and the communication happens automatically.


VIP Member
Since our help desk is staffed 24X7 I built a document on how to do an update package and deploy. If anything 'strange' happens then CNC, which is US based, checks out the issues the next morning, and does the build and/or deploy.

It seems to work out pretty well so that our developers in Europe are able to get a package at the beginning of they day on a regular basis.



Active Member
There is also a custom program called PACKMAN by Forza Consulting that automates the package build process based on OMW status. It can be ran on a scheduler very easily and it can perform a DV and/or PY package build based on standard or custom OMW statuses. It will even promote the project to the next status for you and email a report when everything is complete. If anything errors out, you get an email for that as well. Forza will work with you and can show you a demo as well as help you set it up for your system if you buy from them.


Legendary Poster
Well, actually there is a good reason to have "something" that documents what was changed and why in a package.
When a changes breaks something and the phones start ringing it's nice to be able to look and say "oh yeah - that was changed by Joe and implemented today because Sales wanted the numbers to be sideways ...".

Change logs ARE different and should be separate from Deployments. But knowing WHAT was Deployed WHEN is still very nice to have in a at-a-glance format.
We currently use a quick and dirty sharepoint app for Package requests and deployment management.

Different strokes for different folks and all that.