OMW promotion between 2 oneworld install

[schapron]

Dear list.

I want to know if someone has implemented installation based on B7333 XE where
DV and PY are on physical location with a deployment server / entreprise server / db server
TS (custom env) and PD are on another location with other deployment server / entreprise server / db server

There is WAN link between two plateform.

Is it possible to promote project between PY plateform 1 and TS/PD plateform 2 ??

Is virtual pathcode means something for one of you ?
Is "WAN Configured" box in P0094 ?

Is this kind of installation causing trouble ?

Thanks for your reply.

Seb Chapron.

 

[altquark]

You could always use Pastuhovs' Boomerang to achieve this - located at www.pastuhov.com.au

 

[schapron]

Thanks Jon.. Hi have already suggested this.
Problem is some guys confirm me that this is possible inside JDE but i never listen to this before....in XE...

 

[cassh1]

We have done this since B7321.
We do not have two deployment servers though. This was not necessary and in fact will make it much more complicated.
We have JD/DV/PY on one iSeries with their data bases and WAS servers. And another for PD. Things like the system tables (security, OMW, etc) and OL are on the PD box and shared there by the other pathcodes. We have split the F00950 between machines.

We did installs of Xe (and this would work for any release) on each enterprise server. So each one runs its own kernels and has it's own jde.ini so we can adjust settings differently for test vs prod environments.

There are no issues with OMW transfers as it is all driven by ODBC and datasources - provided you have them all set up correctly to the appropriate machines then you will have no trouble transfering objects between machines.

If you have two deployment servers you will run into trouble with things like the OL files - ie F9861 where the deployment server is hardcoded. I would not recommend splitting them because then you will have to use something like Boomerang or Product Packaging to transfer code.

The WAN configured flag is only to be used for J HTML Web environments (or so we were told by Oracle).

Sue

Xe Coexistent SP22Q1, iSeries V5R2, all client platforms

 

[antoine_mpo]

Hi Seb,

We are in Xe SP20 and we have 2 distinct platforms.
One is located on our production site : it's our DEV/PY/IN platform, with its own data server, enterprise server, deployment server and jas server.
The second one is outsourced : it's our pre-production and production platform, with its own servers.

We make all our developments and parametrization in our platform and do a weekly virtual pathcode for menus/versions/UDC/development promotion from our platform to the outsourced one.

Virtual PathCode is only a problem of CNC set up (servers, data sources, ocm mapping, activity rules).
In our case, the set up is made on the production platform. They declared our deployment and data servers, our PY7333 pathcode and environment, data sources (central objects, versions, business data, control table, Object librarian, Data dictonnary, ...).
Then then use status 21 in OMW for PY and 26 for pre-prod, with activity rules for transfer from PY to Pre-prod.

Once a week, i create an OMW project in PY, put all the objects to promote, and send our supplier a request.
From their side, they transfer the OMW project from 21 to 26, which make all the objects go from our platform to theirs.
It's working fine.

Cheers,

 

[blee]

Hi Sue.

Quoting from a recent post of yours "Things like the system tables (security, OMW, etc) and OL are on the PD box and shared there by the other pathcodes. We have split the F00950 between machines."

My question is about splitting the F00950 between the 2 machines. Did you keep the library and file name the same on both AS/400's or does that cause problems somewhere else?

 

[cassh1]

Hi back,
Sorry for the delay in reply - I just read the summaries in the morning.

We named the library SYS7333TST on our test machine to contain the F00950 for the non-PD environments. I don't think it would matter though because we do have libraries with the same name on both boxes - ie SVM7333. You just have to have the datasources set up for the correct machine. If the datasource name is unique you can have the library name the same.

Sue

Xe Coexistent SP22Q1, iSeries V5R2, all client platforms

 

[njcncadmin]

Hi Antoine,

I know this is an old post, so I'm not sure if you still have this configuration. I have a few questions about this setup.

From your email, it appears that your production site (the one with DEV, PY, and IN) is not in the same physical building as the outsourced site (pre-prod and prod). Is that true? How far apart are the locations? Any ideas regarding the latency between the 2 locations?

When your suppliers do an OMW migration from their status 21 (your PY) to status 26 (their pre-prod), are they accessing the servers at your production site and pulling stuff over the WAN? Any issues with that? Also, from your production site, do you have visibility into what status the OMW projects are at once they get to your outsourced site? Thanks.

 

[antoine_mpo]

</font><blockquote><font class="small">En réponse à:</font><hr />

I know this is an old post, so I'm not sure if you still have this configuration.


[/ QUOTE ]

Yes, we still have it.

</font><blockquote><font class="small">En réponse à:</font><hr />

I have a few questions about this setup.

From your email, it appears that your production site (the one with DEV, PY, and IN) is not in the same physical building as the outsourced site (pre-prod and prod). Is that true?


[/ QUOTE ]
Yes it is
</font><blockquote><font class="small">En réponse à:</font><hr />

How far apart are the locations?


[/ QUOTE ]
I would say something between 300 and 400 km
</font><blockquote><font class="small">En réponse à:</font><hr />

Any ideas regarding the latency between the 2 locations?


[/ QUOTE ]
I don't know. How could i measure it precisely ?

</font><blockquote><font class="small">En réponse à:</font><hr />

When your suppliers do an OMW migration from their status 21 (your PY) to status 26 (their pre-prod), are they accessing the servers at your production site and pulling stuff over the WAN? Any issues with that?


[/ QUOTE ]
Yes they are. They have access to our Oracle databases, and on B7333 sharing of our deployment server. Specifications and files are transfered over the WAN.
No particular issue. But it could take a while, depending on amount of objects to transfer. It's pretty long when you have P4210 in the list ! ;-)

</font><blockquote><font class="small">En réponse à:</font><hr />

Also, from your production site, do you have visibility into what status the OMW projects are at once they get to your outsourced site?


[/ QUOTE ]
No, i can't see from our plateform what is the Status of their OMW projects.
But we have 2 fat clients located in their building that we use remotely (with VNC).
It's helpfull to check some things (over there, they are not JDE expert ... they just use written procedures).

 

[njcncadmin]

Thanks for the information.

To answer your question about how to measure the latency, I don't know how that's done.

 

[indianyogi]

Hi,

I had done this setup between my offshore (India) or onsite(US) location.

We had separate installs altogether (dep server, enterprise etc).

If i remember correctly, I did this:

1. Renamed our DEV environment to XXDV7334. This is based on the fact that 2 DV7334's cannot exist, unless some expert suggests. I think that the data sources got created automatically - through workbech - dont remember.
2. Used DV7334 and changed the pathcode to point to the US deployment server. Pointed all DEV datasources to onsite database server.
3. Create custom OMW project statuses and defined OMW Rules - like: Status A to B - Push objects from offshore env/pathcode/datasource to onsite env/pathcode/datasource.
4. I can say that based on remote WAN setup, we were very satisfied - OMW transfer for 10-15 midsized objects took about 30-40 mins.

The only problem we ran into was that OMW Project information was not getting transferred. But, before we got around fixing that, we had changed our setup to onsite development only. I think a workaround was to run a table coonversion to copy OMW tables - projects to onsite database.

You can ask me more questions - I will try to help as much as I remember.

Thanks
Yogi

 

[njcncadmin]

Yogi,

Thanks for the info.

Our plan differs a little from yours and Antoine's. We weren't planning on having separate installs between the 2 locations. All of our Production servers are going to be moved to Texas (southern, central part of US) and non-Prod servers are being moved to Rhode Island (northeast US). We are planning on keeping our Deployment server in Rhode Island with the non-Prod servers. What we were concerned about were potential issues when migrating from our PT (Production Test) pathcode to Prod and the subsequent package build.

Did we miss anything? Do you think we'll need a separate Dep server in Texas? If so, why?

Thanks in advance for your help.

Cris

 

[indianyogi]

Hi,

Couple of things that I can think of:

As long as you are able to access the UNC \\depserver\share, there should be no problems.

If yes, the only thing I would be concerned is for package deployment. A full package installation over a WAN link, I would definitely be concerned. We tried a full package install and it took about 8 hours(compared to 30 mins) for a typical install(dev objects) over the wan.

You should probably take help your networking team to do some network tests, to ensure that the WAN network can handle the load effectively.

If I can summarize correctly, the only time dep server is used in a PROD env, is for package builds/deployment and client installs.

If you ask me, if the option is available, I would have another deployment server in the PROD location too, to ease the pain in installing/updating clients. Ofcourse, you would have to ensure that the two dep servers stay synched, through various strategies available.

Just my opinion.

I am sure experts can give you better suggestions.

Regards
Yogi

 

[njcncadmin]

Thanks for the feedback. We are planning on having the b7333 share accessible from both locations.

We've already planned on having our networking team evaluate the network as we do an OMW migration to Prod and the subsequent package build/deployment.

As far as when the dep server comes into play, is it the package build or deployment that uses it most? My understanding (at least on UNIX) is that the approriate stuff is copied from the dep server to enterprise server during the build process. And then during the deploy, it's just a matter of the deployment process copying from the packages folder to the pathcode folder.