Process question

[Phoenix789]

Hi

Need your thoughts on Customers who are on E1 and are a 24/ 7 and 365 days shop. How do you handle JDE Day to Day or weekly promotions .

As of now I think deployment needs you to bring the system down but this is not acceptable for some Customers.

How do you handle promotions in such cases ??

I am sure there are many customers who are a 24/7 shop and need a way to handle thier daily or weekly promotions without bringing the system down.

Regards
Pete
E1 9.00 ,8.98.2 Toolset
Oracle Database

 

[Chan Rana]

For development i dont think this will affect the Production box. If this is the case then i would recommend to move DV & PY out of PD box. For PD there is always a change management process setup in company(or should be setup) so you can move the changes to PD mostly during Sunday or during night (mostly around early morning for most of the 24x7 system on weekend). The frequency can be one in a month or week depending on the nos of changes you have during the period and also based on your company change mgmt policies.

Hope this helps.

Chan

 

[Phoenix789]

Hi

First of all thanks for your reply.

I agree with your answer and this is how we usually implement at client places, but the business process at this client plaacce doesnt allow any downtime as they are a 24 X 7 and 365 days .

I was wondering how other companies handle this if they are facing the same issue and is there any other way to handle this

regards
pete

 

[Terry Duffy]

We have a customer that is also a 24*7 shop on E811 SP1.

They are still in a heavy roll out schedule (after being live for 3 years) and are currently live in over 40 countries with 20+ still to go.

We have lots of update packages in DV and PY but tend to try and group projects together for deployment to production.

We tend to deploy at 6am (UK time) on weekdays (when the customer decide they need the build to happen), for 2 main reasons:-

1. We have noticed that this is the quietest time for UBE's to be running.
2. We have the lowest number of users working on the system at that time.

Should their be a problem with the deployment at that time and we have to restart the system (which has happened a few times - with kernels not responding to the lock request on the logic server) then this causes the user population the minimum amount of disruption.

You need to analyze your user load to see when your minimum workload is to suit your situation.

Full package deploys tend to happen on a Saturday as in some countries Sunday is a working day.

 

[ice_cube210]

Pete,

I would suggest posting this in the EnterpriseOne forum as this is more a CNC operational / Architecture question.

I say architecture because , the right design will allow you to perform deployments while maintaining a 24/7 up time. There are several JDE customers around the world that do this.

In short it would mean having multiple Web , App and Batch servers grouped in such a way that one half of it can be taken down while still keeping the application up an running and that they sized accordingly that they can still take on the user load during your non peak hours.

 

[DBohner-(db)]

Another suggestion, piggy-backing off of Chan's....

Put Production on another box. That way - any testing / updates / fixes / ESU(s)... do not affect LIVE. All it takes is for one ESU to touch a Data Dictionary Item - and all hades comes a visiting.

Segregation can go a LONG way to keeping a 24/7 shop up.

(db)

 

[E1_Raider]

Our Package Build schedule is Update Packages are done weekly (as needed), and Full Packages every other month (unless required sooner).

We are not a 24/7 shop but this is what we do to limit the disruption for our HTML users (picked up this tip at PeopleSoft|Connect in 2004!). Our Enterprise Server is an iSeries, so we created two sets of libraries (JASPDA and JASPDB), along with OneWorld Datasources.

We setup two sets of OCM mappings for the F989998 and F989999 tables (serialized objects) in each datasource. One for *PUBLIC, and another set for a Generation user, such as JASGEN, that points to the opposite set of tables when we generate. So, for example, we point *PUBLIC to JASPDA datasource and set JASGEN to use datasource JASPDB to generate to. When the generation completes, and we are ready to switch Production to JASPDB, we just change the Active OCM mappings and bounce our Web Server application instance (which only takes a minute).

We been using this method for the last six years and has worked well for us. It also gives us a backup set of serialized objects in case the newly generated ones have problems.

 

[Chan Rana]

Pete,
I dont think there is way to deploy the package in PD without recycling the server unless some CNC here have any idea. I think as posted in one of the post you/cient need to analyze the quiet period during the day or week when you can schedule the deployment.

As i have found in most of the banks you can post the msgs on site when the scheduled down time is before hand so users are aware off. You you can design a form which is displayed during downtime for use to comeback after 30mins etc.

Chan

 

[Phoenix789]

Hi all

Thanks everyone for all your replies.

I am sorry I didnt place it at the right place.

We can definetely seperate out the Dv and Py from Production .
But there is a challenge when you have a change which needs to go in to Prod and you cannot afford to take the System down, I know this is not possible and I have never seen system which dont go down . I am just throwing this out to see if someone faced the same issue and have a workaround for it .

Once again thank you all for the inputs look forward to more.