Package Assembly and Versions

[sashton]

Ok List, I did quite a bit of searching through the site and I saw some references to this but no overall opinions. Here is the scenario. We support multiple completely separate instances of E1 and so in order to simplify our build procedures we do the following:

We have a nice well organized status driven system in OMW that provides a "checks and balances" atmosphere so CNCs and developers can look at a status and tell exactly where their project is in the lifecycle. That all works great.

The other thing we do is only assemble packages based on project name and not by doing an object by object build.

The issue we have run into and what appears to be happening is that a developer will create a project with nothing but versions in it and when it comes to assembly time, we put in a package name and nothing shows up on the assembly screen. Alternately, you can't simply check the object out in the project and then erase the check out so that even if the project holds the token for that object, the assembly still only sees it if the object has been checked in to that project.

So my overall question is, do you require your developers to include the base report template in the project and to check it out and back in to the project or do you build object by object package assemblies?

The developers are hesitant to check out and back in a UBE base template that they haven't modified or touched at all because now their name gets attached to it in the OMW logging and they didn't really do anything to it. This has to be done just so that the report will show up in the package assembly process. Others viewpoints?

 

[gregglarkin]

[ QUOTE ]

The other thing we do is only assemble packages based on project name and not by doing an object by object build.

The issue we have run into and what appears to be happening is that a developer will create a project with nothing but versions in it and when it comes to assembly time, we put in a package name and nothing shows up on the assembly screen. ......

So my overall question is, do you require your developers to include the base report template in the project and to check it out and back in to the project or do you build object by object package assemblies?



[/ QUOTE ]

Steven,

In our shop, 99% of the package builds are full builds. We build and deploy a full PY weekly. We build and deploy a full PD three times a month, omitting the week around month end closing.

Since we do full builds, I don't care what changed, I don't have to track projects, I don't have to worry about missing objects. It's a very clean and simple process that has worked for us for the last ten years.

1% of the time, I will build an update package. If a developer tells me that they made changes to x y and z versions of objects blah blah and bleck, I don't really care. I don't build an update with just the versions that they changed. I will grab the objects that changed and all of the versions associated with that object for the update package. Haven't had any complaints yet.

- Gregg

 

[Jeremy M.]

For some of my clients building a Full Package takes 8 hours compared to a 30 minute Update Package. I generally build and deploy Fulls once a month. I do build my Update Packages based off of OMW Project names as well and yes, I make the developers check out and back in the base object. Just makes it so much easier for me.

 

[cncjunior1]

The package assembly screen does not list any versions when searching by project so it will only pull anything that's not a version and has been modified under that project name you're searching on.

I generally always build all versions when I select a UBE, so even if there are just a couple version of a single UBE in the project I just pull up the UBE object name and select that. We don't require the developers to check out and check in the UBE when just version changes are needed for the exact reason you stated, makes it harder to figure out when a change was really made to the template.

 

[Terry Duffy]

I believe that your issue stems from the fact that the majority of objects when amended get the project name added to the F9861 table in Object Librarian (Field SIMOCDMT). The F9861 only holds records for the main object and not versions.

The F983051 table DOES NOT have a field that can be used to hold the project name and therefore when looking for objects that have been amended in a project you will not be able to find any versions for objects.

It is a design flaw that I have asked to be rectified in some way in future modifications of the package build process.

If I remember correctly the main issue here is that versions can be created from Batch Versions and not only in OMW and therefore the records for versions created this way go into users default OMW project (which is not always at the correct status for the environment created in) - and then you also have the added complication of web only versions.

So I am afraid the answer is that there is currently NO solution to your issue - you need to check each project in OMW before you define your package and where the project has an entry for an application/report version without the application/report as well then you have to manually search for the application/report and then select the appropriate version yourself.

 

[gregglarkin]

[ QUOTE ]

So I am afraid the answer is that there is currently NO solution to your issue - you need to check each project in OMW before you define your package and where the project has an entry for an application/report version without the application/report as well then you have to manually search for the application/report and then select the appropriate version yourself.

[/ QUOTE ]

Or..... save yourself some time and build a full package.

Building is the easy part. Sure, fulls take longer, but if you submit them at the end of the day, they'll be ready by morning. Deploying is where the cnc skill set comes in to play.

 

[Terry Duffy]

When you are in a global roll out situation (32 countries already installed and another 32 by the end of this year) and you have 14 JDE installed languages and 21 Vocabulary Override languages (where we have not installed the full JDE language) then FULL builds and the following generations (E811_SP1) take longer than 8 hours. The generation alone takes 18 hours.

The versions for a new country implementation take 1hr 30 minutes to build, deploy and generate per pathcode and about 35-45 minutes to get the versions selected into a package assembly - due to the issue Sean referred to.

So it is horses for courses I am afraid.

 

[brother_of_karamazov]

[ QUOTE ]
[ QUOTE ]

So I am afraid the answer is that there is currently NO solution to your issue - you need to check each project in OMW before you define your package and where the project has an entry for an application/report version without the application/report as well then you have to manually search for the application/report and then select the appropriate version yourself.

[/ QUOTE ]

Or..... save yourself some time and build a full package.

Building is the easy part. Sure, fulls take longer, but if you submit them at the end of the day, they'll be ready by morning. Deploying is where the cnc skill set comes in to play.

[/ QUOTE ]


You'll change your tune when you get to the web.

 

[sashton]

Yes, we have several instances that take 12-14 hours to build full packages and trying to get one in overnight is not the easiest thing to do. I don't want to have to build a full package just to add three new reports. An update package will take 10 min and I am out the door. I have no problem informing the developers that they need to include the base reports in their projects and that all objects in the projects need to be checked out and back in to that project. If they don't want their name attached to it, then I will check the project out and back in for them.

I was just curious to see what others were doing on this. Perhaps a future release will not have this "bug".

 

[brother_of_karamazov]

[ QUOTE ]
Yes, we have several instances that take 12-14 hours to build full packages and trying to get one in overnight is not the easiest thing to do. I don't want to have to build a full package just to add three new reports. An update package will take 10 min and I am out the door. I have no problem informing the developers that they need to include the base reports in their projects and that all objects in the projects need to be checked out and back in to that project. If they don't want their name attached to it, then I will check the project out and back in for them.

I was just curious to see what others were doing on this. Perhaps a future release will not have this "bug".

[/ QUOTE ]

I generally do something similar to what you do - All versions must have the template and I checkout/in the project prior to the build.

 

[Terry Duffy]

Checking out the report/application every time will at least present the application/report in the package contents screen. I am not in favour of choosing select all versions as I try and copy the DV package to quickly make up the PY package. This could lead to random errors in PY as you could have included a version that is present in DV BUT that has not been promoted to PY yet.

The other draw back to having the developer check out and in the base application/report when just creating a new version is that you could lead to object contention with a developer making changes to the base object and another business anlyst / developer responsible for just creating versions. You could end up with unnecessary token queueing.

It all depends on how active your development team(s) / business analysts / support teams are.

It should not add much of an overhead to check the objects in the project (especially if you already have to add yourself as a user to promote the project).

As I said earlier it is all horses for courses (dependent on your release of software - whether you have to generate objects or not / the number of update packages you create daily / weekly (my average is about 20) - how active your development team(s) are and how popular the object is that you are getting versions for).

That is the beauty of JDE - we can all create processes that work fine for the particular situation we find ourselves in.

I have 7 different customers and my process is adapted for each (ranging from NO development whatsoever - therefore very few builds required to daily update packages and multiple languages). Whatever works for you.

As I mentioned earlier I was asked to provide some input into a list of enhancements and to rate them on the package process. This was one of the ones I asked to have added. Another that is a headache on this same topic was that the generation process does a generation of ALL versions for an application/report even if you have only added one because the generatorlist.txt used by the bulk generation process does not specify versions just the application or report again adding unecessary time to the process.

 

[pshearer]

I've handled it by writing a custom front-end for package assembly. What is does is lets you query the OMW table for any project at a given status code and then sucks the objects and versions out and defines an update package for them. When it pulls out the version it will automatically include the base object the version was based on.

If your interested in getting this front-end give me a call or shoot me an email.

-Paul