Architecture of REMOTE ONEWORLD SYSTEM

One for the architectural wizards...

JDE System Europe comprising :
'Development' Ent Server NT
'Development' Dep Server
main functional and technical people.
path codes DV7333 PY7333 PP7333 (preprod) PD7333

JDE System "Other Side of the World" comprising :
'Production' Ent Server NT
'Production' Dep Server
TSE Server
users
path codes PP7333 (preprod) PD7333


Assumptions.
* Development volume LOW, done in Europe
* Configuration done in Europe
* net connection VERY UNRELIABLE

the Challenge(tm) is this:
Basically, changes to the system (ESUs, versions, configuration, but very little custom dev) will be done at hq in Europe.

We need to transfer these changes to the system 'on the other side of the world'. Remember, the net connection cannot be relied on, so we assume worst-case that we must burn CDs and post them.


OPTION1:
Build packages in Europe.
Burn client+server packages onto CDs.
Export Versions - PP7333 and Versions - PD7333 onto CD.
(for processing options which are not included in package)
... post CDs...
remote site:
import Versions from CD.
Load packages onto 'production' dep server and ent server.
deploy packages.

disadvantage- cannot rebuild packages at remote site.


OPTION2:
Export Central Objects - PP7333 and - PD7333 onto CD.
Export Versions - PP7333 and Versions - PD7333 onto CD.
... post CDs...
remote site:
import Versions and Central Objects from CD.
build and deploy package

disadvantage - need package building expertise at remote site.


Has anyone done something like this ???

Can anyone see an easier way to do this, or offer some comments on the above ???


Cheers,
Steve Murphy
Xe SP18 XU3 NT SQL2k TSE.

Why not

1. invest in a DVD burner (Europe) and a DVD player (other side of the
World).
2. deploy all your changes as you wish in Europe.
3. burn B7 directory for Client/Server (or just the PP7333 and PD7333
directories) on to the DVD.
4. ship the DVD to the "other side of the World".
5. copy off the DVD as XX7333TMP to save downtime.
6. bring down One World.
7. rename the current working directories to XX7333DATE.
8. rename XX7333TMP to XX7333.
9. bring up One World.
5. also do an export of your version tables (4 total) and import on the
other side.

Total downtime per system change - 10 minutes. Total investment - $800.
Total chance of corruption or wacked specs, etc. - <0.09%.

I do something similar to this every week except for the whole across the
world part.

Just my 2 cents.

Mark Siebenschuh



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

Steve,

If it were not for the fact that you have said that you will not have technical expertise at the production site, I would recommend Product Packaging -- Build your own ESU/ASU to do the distribution.

In B7332 it worked painfully, in XE it pretty much works as advertised. However, it will require the same skill set (or more) as package builds.

Question: If you do not have enough technical expertise to manage package builds at the Production site, who is going to be doing all this tricky database importing from CD?

Regards,

Justin Miller
Teamspot Oy
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX

Hi Steve,

I agree with Justin, Product Packaging might be an easy way to transfer objects from Europe to the other side as long as you are not talking about many objects. For ESU applied, you can use PC Anywhere to connect to the other machine (I know that JD Edwards does not like but worst case you can).

Adrian Valentim
Valmatrix Consulting Inc.

Assuming you could get some sort of connection to the remote Production site every now and then (say once every couple of days), you could set-up a "remote" environment/pathcode on your Development system. You would need to make some changes to your Transfer Activity Rules (or cheat and use OL) but this would effectively allow you to move objects from one site to the next without having to burn onto CD. I move objects from one site to another over a Sat. link using this method, but it's a 2MB link and it's fairly reliable. You would still have the issue of having to get someone to build and deploy the packages on the remote site, I do it myself remotely but it shouldn't be that difficult to show someone how to do this, but would you want a non-technical person deploying packages in your Prod Env.?

Phil Anderson.
[email protected]
W2K/SQL2K/MSCS
Xe SP18/Update4

Steve :

I would use JDE Object Packaging (to define and build an ESU) to
transfer object modifications across your two sites.
It's a safe, platform independent, "CDROM enabled" and easy way to
transfer objects across installations.
Package building expertise can be solved by remote administration
software such as PCAnywhere, RAdmin, etc.
We all know that PCAnywhere is not accepted by JDE, but I've tested
that you can connect to a remote Deployment using it, define a package,
and just after submitting it hang your connection. You let the
package end without your remote interference (about 4 to 6 hours), and
you connect again to check the package PDF, its logs and deploy it.

Sebastian Sajaroff

Seems like you have a HUGE risk factor if your Production system goes down, considering you don't have any CNC person there to support it, and your remote connections to it may be unreliable. You may want to push for some sort of investment in a more reliable remote connection, this way it would alleviate some of the risk if the system went down, and you could perform deploys in a more reliable fashion.


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

Re: RE: Architecture of REMOTE ONEWORLD SYSTEM

Mark
in the scenary of DVD's what happend with the central object in the database (oracle in my case).
when the client make a JIT for a new object, this object is reader by the enterprise server not by the deployment.