Deploying Modifications

Hi List,


I have a query from one of our developers.....
Can anyone out there point us to a document which details what types of modification needs an update package and deploy and what doesnt? For example if new versions of an application are created with new processing options, does this require a client package so as all other fat client users can get it?

Thanks,

Maria

These objects (the OMW definition) require a deployment:
(These are central object based)
BSFN
UBE
APPL
BSVW
DSTR (both regular and PO template)
TBLE


These do not:
(These are data based)
UDC
MENUS
DD Items
Workflow (I think)

These obects depending on what was changed*:
Application Versions
Batch Versions

*If only Processing options were changed then NO deployment is needed. If
data selection or user overrides are changed then a deployment is needed.
This means that IV (interactive versions) almost never need to be deployed
(only if overrides are set) as there is no data selection on them



Aaron Walsh

A fat client should be able to JITI down a new version of an application and would not require a update package.

Hi Ken
That is true if the version does not exists on the fat client or target location. If you are modifying the version( changing data selection) then the modified version is not JITI Down. In this case you will have to build the update package for the batch version

Hope it helps

For batch versions check out the KG document OTT-02-0005. gm.

ENT: AS400 V4R5 OW Xe Update 5 Coexistence SP19 D1
DEP: NT 6a SQL 7 SP3
JAS: Win2000 (pending)

Hi List,I have a query from one of our developers.....Can anyone out
there point us to a document which details what types of modification
needs an update package and deploy and what doesnt? For example if new
versions of an application are created with new processing options, does
this require a client package so as all other fat client users can get
it? Thanks,Maria
OW Xe / JAS SP17.1(AIX RS6000 Web/Ent Server)
Oracle 8.1.7
--------------------------
To view this thread, go to:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=40380

+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World« / XE mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com

JDEList is not affiliated with JDEdwards«

+ - - - - - - - - - - - - - - - - - - - - - - - -+



AS400 V4R5 Coexist CO-NT Xe SP19

Re: RE: Deploying Modifications

Aaron,

batch versions require deployment via package.

RE: RE: Deploying Modifications

Larry-

I always thought the same thing. However, very recently I did some testing.
I had two fat clients and a third computer with a citrix connection. I
changed a Processing option on an existing Batch version on one fat client
and then (immediately) viewed that same version using the other fat client
and via citrix. On both of the other machines the PO value was updated.

I am not sure when this changed, but it seems to work for me...

One caveat is with versions that are on scheduler. In order for the changes
to take place the version must be deployed or at least have the version
spec's submitted to the sever.

Perhaps you can run a similar test as I described I would be curious if
anyone else has this functionality

I am on Xe sp 18 with Update 3 (plus a few ESU's) NT deployment server,
Oracle database. The only thing we are doing here that I haven't really
seen before (then again I have never really looked or cared) is that central
objects sits on our database server and not on the deployment server.

Aaron Walsh

Re: RE: RE: Deploying Modifications

Hi Aaron
Processing options are stored in Tables. So does not require package build. But if you changing something that is part of spec then you may need. For example you change the data selection on the batch version.. it is part of spec.
The confusion about building/not building the update package for version is due to that Batch versions are JITI down to the target machine if they does not exists. For Example you create the new batch versions in Dev and promote it to PY and some users need to test this version then version will be JITI down ( If the JITI is enabled at the environment level). Now let us take the other case that you are modifying the data selection of the version that is already exists in PY environment. Now once you promote the project then it updates the Cental Objects database table. But this version will not be JITI down because it already exists. So in this case you will have to build the update package.

Hope this helps you.

Re: RE: RE: Deploying Modifications

As Vivek points out we're both right Aaron.

Changes that only affect the values of Processing Options are immediate and do not require an update package (same as a Application Version).

Changes that affect specifications (Data Selection values, Data Structure, or Version Specific UBE Overrides) DO require an update package to distribute changes.

I'm sure this subject will continue to be-devil JDE users for years to come

Re: RE: RE: Deploying Modifications

In the original question, the person said that they modified the processing template - added new processing options. Doesn't that new template have to be built into an update package?

Re: RE: RE: Deploying Modifications

Yes.