Where to build packages from?

[MagarG]

We got used to building update packages from our deployment server
logged onto the DEP7333 environment but not sure if this is correct to
do this. Before we did this we had to logon to DV from a workstation
to setup the package assembly. We did this because custom versions do
not show up on the deployment server (logged is as DEP7333) because the
F983051 versions tables is mapped to Oneworld Local. On the KG, sar
3816056 mentions this. If I logon to DV, PY, PD on the deployment
server, I get a bunch of errors because the OCMs are not right.

Is it common to use DEP7333 to build packages? Should I change the
mapping for the F983051 for OneWorld local to point to our versions so
they get picked up? Should you be able to even logon to DV, PY, PD at
the Deployment Server? Where do I build the PY Package once the project
is promoted from DV, do I have to be logged onto PY? Looking for
insight on practices out there. Thanks. Grant.

ENT: AS400 V4R5 OneWorld Xe SP16.1
DEP: NT 6a SQL 7 SP3




AS400 V4R5 Coexist CO-NT Xe SP16.1
Websphere 3.5.4 on AS400 JAS SP16.1

 

[msouterblight1]

This is a commom practice, and in general, having the versions in a package won't matter, as they will get jiti'd down to the workstation if they aren't there. There are some cases in which it is good to include the versions in the package, but generally you don't need them to be there. I wasn't clear on something in your post, however. Are you logging in to DV, PY, and PD on the Deployment Server and getting those errors, or a development workstation? If you are trying to access those environments from the Deployment Server, you are getting those errors because the INI file lists OneWorld Local as the initial datasource for log-in. There are 2 things you can do here.

1. Copy the jde.ini file on the deployment server, so you have a backup, then go ahead and change the ini entry to point to your system datasource instead of local. In this way you can switch between the two ini's.

2. You can (if you don't have one already) perform the builds from a dewvelopment workstation.

Hope this helps.

Matthew Scott
XE, SP 17.1, AS/400, Win2000 Logic Servers, Win2000 Term. Servers, Win2000 Java Servers, Central Objects in Oracle.

 

[adri_valentim]

Hi Grant,

Just to let you know, it is recommended that you build packages from the deployment server in the DEP7333. Check the OCM mappings locally on the deployment server. For all environments, they should be pointing to the respective environment and the DEP7333 should be pointing locally (no mappings). That is okay.



Adrian Valentim
Valmatrix Consulting Inc.

 

[SULLY1]

Grant

I build packages from a development workstation in the pathcode that the package is for to get the versions. We change versions alot and I don't believe they jiti down if the version already exists on the client workstation or the server(I could be wrong).

If there are business functions in your build you will need to delete a temporary file that is create during the build for that pathcode called BusObj. I was told by JDE CNC trainer that this is still a problem with XE(not deleting this folder). This folder seems to cause problems with server builds on subsequent builds.

If the build effects a system .dll like CINSTALL.dll. Then I assemble and build the package in the pathcode of deployment, but submit the build it in a different pathcode. I've had errors like file in use if I don't build in a different pathcode.

Hope this helps.

Patty

B733.1\SP7.1\Oracle 8.0.5\Ent HP-UX 11.0

Upgrading to XE\SP15.1\U3

 

[msouterblight1]

Sully / Grant:

It is true that a version will not get jiti'd if it already exists. However, what I gathered from Grant's post was that he was including the UBE in the package. If this is the case, the Version specs for the UBE in package will be cleared when the package is deployed. This is how a build from DEP7333 works, as the OCMs for the F983051 point to Local instead of System.

Hope this helps.

Matthew Scott
XE, SP 17.1, AS/400, Win2000 Logic Servers, Win2000 Term. Servers, Win2000 Java Servers, Central Objects in Oracle.

 

[MagarG]

to DV, PY, and PD on the Deployment Server and

Logging onto the Deployment Server. What about update server builds
and custom UBE versions? For example, R43500|VERSION1. I created the
server update package assembly in DV (so I can see the version). Now, I
goto the deployment server and log onto DEP7333 and run the update
server package. Will this UBE version get picked up since F983051 is
pointing to Local and it isn't in there?

gm

ENT: AS400 V4R5 OneWorld Xe SP16.1
DEP: NT 6a SQL 7 SP3

This is a commom practice, and in general, having the versions in a
package won't matter, as they will get jiti'd down to the workstation if
they aren't there. There are some cases in which it is good to include
the versions in the package, but generally you don't need them to be
there. I wasn't clear on something in your post, however. Are you
logging in to DV, PY, and PD on the Deployment Server and getting those
errors, or a development workstation? If you are trying to access those
environments from the Deployment Server, you are getting those errors
because the INI file lists OneWorld Local as the initial datasource for
log-in. There are 2 things you can do here.

1. Copy the jde.ini file on the deployment server, so you have a
backup, then go ahead and change the ini entry to point to your system
datasource instead of local. In this way you can switch between the two
ini's.

2. You can (if you don't have one already) perform the builds from a
dewvelopment workstation.

Hope this helps.

Matthew Scott
XE, SP 17.1, AS/400, Win2000 Logic Servers, Win2000 Term. Servers,
Win2000 Java Servers, Central Objects in Oracle.
--------------------------
Visit the forum to view this thread at:
http://www.jdelist.com/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=OW&Number=27275

+ - - - - - - - - - - - - - - - - - - - - - - - -+
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 SP16.1
Websphere 3.5.4 on AS400 JAS SP16.1

 

[msouterblight1]

In this case you should perform the assembly, and the build from the DV environment. You could also perform the deploy from there, but it isn't necessary.



Matthew Scott
XE, SP 17.1, AS/400, Win2000 Logic Servers, Win2000 Term. Servers, Win2000 Java Servers, Central Objects in Oracle.

 

[msouterblight1]

I forgot to mention something else. If you want to deploy version changes to your Enterprise/Logic server, you can do so without building a package. Before you click submit, go to Advanced (on the exit bar) and select submit version Specifications Only. This will update the Enterprise/Logic Server with the new version specs.

I hope this helps.

Matthew Scott
XE, SP 17.1, AS/400, Win2000 Logic Servers, Win2000 Term. Servers, Win2000 Java Servers, Central Objects in Oracle.

 

[MSiebenschuh]

Well here is my 2cents -

1. We build full packages for all environments once a month (we do
lotsssssss of mods)
2. We build all packages from DEP7333 on the deployment server
3. We deploy all packages from DEP7333 on the deployment server
4. We always include ALL version when we build a package with a UBE

We average at least 3-5 DV packages a day, 2 PY packages a day and 1 PD
package a week.

5. To deploy to PD (we have 30 Citrix servers and 3 Enterprise/App servers)
we simply build/deploy the package as listed above but instead of deploying
to PD we have another environment for final approval/training called TN.
This environment uses the same code as PD of course. Once it is deployed to
our single TN Citrix server and single TN Enterprise server we simply copy
it to all the real PD boxes as PD7333TMP. Then come 2 in the morning we
bring down OW rename all the directories (takes about 10 minutes) and bring
it all back up. Thus I can service the soon to be 1000+ users with only 10
minutes of downtime per week.

None of this requires anything really funky. No files to change on my
deployment server, no ocm mappings to bother with, no worries about crushing
my deployment server with a bazillion fat-client deployments (which aren't
any faster and definitely not as easy to maintain) , and I know everyone is
running the exact same code for troubleshooting purposes (except developers
of course). I like to keep things simple.

Mark Siebenschuh



Mark Siebenschuh
HP9000/Oracle 8.0.5/JDE XE/Lots of Citrix

 

[adri_valentim]

Re: RE: Where to build packages from?

Hi Mark,

Point 5: This is an excellent way to do it. I have used this approach in te passed.

Also, when I build packages from the deployment server, I have never seen JITI's of versions on the clients, so the specs do get created for custom versions during the build.

For MagarG questions on Custom versions of Reports. I usually do the Package Assembly from a fat client to be able to select the version and then build it from the deployment server.


Adrian Valentim
Valmatrix Consulting Inc.

 

[MSiebenschuh]

RE: RE: Where to build packages from?

You are correct and as we all know JITI is no good on a Citrix farm.

Mark Siebenschuh




Mark Siebenschuh
HP9000/Oracle 8.0.5/JDE XE/Lots of Citrix

 

[brother_of_karamazov]

Assemble the package in the desired environment, then
build on the Deployment Server- if you feel you need
to. That way you will see the versions and can select
them and you build from the strongest box.




--- MagarG <[email protected]> wrote:
http://www.jdelist.com/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=27273


__________________________________________________

 

[brother_of_karamazov]

I don't think so. This will only update the version
with changed Data Selection and Sequencing. If you
want others to see full spec changes you will still
need to deploy.


--- msouterblight1 <[email protected]>
wrote:
http://www.jdelist.com/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=OW&Number=27295


__________________________________________________

 

[DSauve]

Thanks, Matthew, for the tip on Submit Version Specs Only from the Advanced tab when submitting a UBE to the Enterprise server.

Sef, I think this would make a good addition to the Tips & Tricks forum.

With regards to versions and whether they update, it's been my experience that if you change a processing option on a UBE version, that change takes effect immediately across the board (for that environment), so no other update to clients or server is needed. However, if you change the data selection, and the version is already loaded on the clients or server, the new data selection will NOT automatically appear on the clients or server. Thus, you'd need an update package with the version being changed to update clients. You can use an update package to update the server, or you can do as Matthew suggested and just Submit Version Specs Only.

Don Sauve
Wagstaff, Inc.
OW XE, SP15.1, HP-UX 11.0, Oracle 8.1.6

 

[Bob_Duben]

My $0.02 worth,
Two points I might try to clarify.

A. Where you do the builds can be significant as it relates to build time.
I ran full package builds for the DV environment on my Deployment server (2)P3-500mhz 1gig ram and my development PC Celeron 900 512m ram, both NT4.0 SP6a. The PC beat the Deployment server by 2 hours for the client portion of the build, 7 1/2 as compared to 9 1/2 hours. The AS/400 server part of the build was 6 1/2 hours.

B. Versions, I have built about 200+ update packages mostly to deploy custom/modified versions in the last year. When a user accesses a new version it does JITI to his/her PC. When that same version is modified, anyone who has already JITI'd it once will not get any changes unless it is deployed in either an update or full package.

clear as mud right?

Bob Duben

*JDE CNC, CMA
AS400@V4R5, Xe SP16.1 XU3/A73 CUME11, CoExist, NT4.0 (SP6a), NT4.0 Citrix, Win2k Citrix XPe
500 mixed clients