Best practices for promotions to production

My company's production environment is way to lose, I need to implement some controls. My analysts keep fouling up the production objects. Does anyone know of best practices for an organization rolling out production changes?
thanks

Yes you can. With SOA 11g, you can create deployment profiles to change poperties during deployment. You can also build your own deployment mechanism, as I did.
http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html
Marc

Similar Messages

Best practice for promoting roles

I would like to know what is the best practices for promoting Administrative and/or normal Roles between environments. If I make a change to the capabilities of a role, I'd rather not create a whole new build if I didn't have to. Would exporting from debug, and importing via 'lh import' suffice, or is there an easier/better method?
Thanks

Hello,
I'd ask in the Windows forum on Microsoft Community.
Karl
When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer.
My Blog:http://unlockpowershell.wordpress.com
My Book:Windows PowerShell 2.0 Bible
My E-mail: -join ('6F6C646B61726C40686F746D61696C2E636F6D'-split'(?<=\G.{2})'|%{if($_){[char][int]"0x$_"}})

Best practices for a development/production scenario with ORACLE PORTAL 10G

Hi all,
we'd like to know what is the best approach for maintaining a dual development/production portal scenario. Specially important is the process of moving from dev. to prod. and what it implies in terms of portal availability in the production environment.
I suppose the best policy to achieve this is to have two portal instances and move content via transport sets. Am I right? Is there any specific documentation about dev/prod scenarios? Can anybody help with some experiences? We are a little afraid regarding transport sets, as we have heard some horror stories about them...
Thanks in advance and have a nice day.

It would be ok for a pair of pages and a template.
I meant transport sets failed for moving an entire pagegroup (about 100 pages, 1Gb of documents).
But if your need only deals with a few pages, I therefore would direclty developp on the production system : make a copy of the page, work on it, then change links.
Regards

Best practice for test to production

I actually only have one server for test and production, but the dev processes all point to development databases and the production processes will point to production databases.
The only real change is to make the JMS queue points to prod vs test. There doesn't seem to be an easy way to copy a complete process and change the name. That would work best for me.
Any ideas?
Edited by: ss396s on Nov 19, 2009 9:21 AM

Yes you can. With SOA 11g, you can create deployment profiles to change poperties during deployment. You can also build your own deployment mechanism, as I did.
http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html
Marc

Best Practice for deploying in Production Cluster

          I have the following.
          2 Physical machines each running 2 jvm's, thus I have 4 jvm's in my cluster.
          We access the jvm's via an IIS plug-in.
          When it comes time to do a new .war file migration, do you need to stop the jvm's
          first ?
          I have tried deploying with the jvm's live, it technically worked but we then
          noticed several 404 errors during the day on a servlet that was there. (Called
          successfully around the 404)
          Anyway, I'm just looking for recomendations on how others deploy to production.
          Tim


          Tim wrote:
          > I have the following.
          >
          > 2 Physical machines each running 2 jvm's, thus I have 4 jvm's in my cluster.
          >
          > We access the jvm's via an IIS plug-in.
          >
          > When it comes time to do a new .war file migration, do you need to stop the jvm's
          > first ?
          You should be able to redeploy a web application without any
          problems? When you get this 404 errors, do you see any stacktrace
          on the server window
          Kumar
          >
          >
          > I have tried deploying with the jvm's live, it technically worked but we then
          > noticed several 404 errors during the day on a servlet that was there. (Called
          > successfully around the 404)
          >
          > Anyway, I'm just looking for recomendations on how others deploy to production.
          >
          > Tim

Best practices for setting up projects

We recently adopted using Captivate for our WBT modules.
As a former Flash and Director user, I can say it’s
fast and does some great things. Doesn’t play so nice with
others on different occasions, but I’m learning. This forum
has been a great source for search and read on specific topics.
I’m trying to understand best practices for using this
product. We’ve had some problems with file size and
incorporating audio and video into our projects. Fortunately, the
forum has helped a lot with that. What I haven’t found a lot
of information on is good or better ways to set up individual
files, use multiple files and publish projects. We’ve decided
to go the route of putting standalones on our Intranet. My gut says
yuck, but for our situation I have yet to find a better way.
My question for discussion, then is: what are some best
practices for setting up individual files, using multiple files and
publishing projects? Any references or input on this would be
appreciated.

Hi,
Here are some of my suggestions:
1) Set up a style guide for all your standard slides. Eg.
Title slide, Index slide, chapter slide, end slide, screen capture,
non-screen capture, quizzes etc. This makes life a lot easier.
2) Create your own buttons and captions. The standard ones
are pretty ordinary, and it's hard to get a slick looking style
happening with the standard captions. They are pretty easy to
create (search for add print button to learn how to create
buttons). There should instructions on how to customise captions
somewhere on this forum. Customising means that you can also use
words, symbols, colours unique to your organisation.
3) Google elearning providers. Most use captivate and will
allow you to open samples or temporarily view selected modules.
This will give you great insight on what not to do and some good
ideas on what works well.
4) Timings: Using the above research, I got others to
complete the sample modules to get a feel for timings. The results
were clear, 10 mins good, 15 mins okay, 20 mins kind of okay, 30
mins bad, bad, bad. It's truly better to have a learner complete
2-3 short modules in 30 mins than one big monster. The other
benefit is that shorter files equal smaller size.
5) Narration: It's best to narrate each slide individually
(particularly for screen capture slides). You are more likely to
get it right on the first take, it's easier to edit and you don't
have to re-record the whole thing if you need to update it in
future. To get a slicker effect, use at least two voices: one male,
one female and use slightly different accents.
6) Screen capture slides: If you are recording filling out
long window based databse pages where the compulsory fields are
marked (eg. with a red asterisk) - you don't need to show how to
fill out every field. It's much easier for the learner (and you) to
show how to fill out the first few fields, then fade the screen
capture out, fade the end of the form in with the instructions on
what to do next. This will reduce your file size. In one of my
forms, this meant the removal of about 18 slides!
7) Auto captions: they are verbose (eg. 'Click on Print
Button' instead of 'Click Print'; 'Select the Print Preview item'
instead of 'Select Print Preview'). You have to edit them.
8) PC training syntax: Buttons and hyperlinks should normally
be 'click'; selections from drop down boxes or file lists are
normally 'select': Captivate sometimes mixes them up. Instructions
should always be written in the correct order: eg. Good: Click
'File', Select 'Print Preview'; Bad: Select 'Print Preview' from
the 'File Menu'. Button names, hyperlinks, selections are normally
written in bold
9) Instruction syntax: should always be written in an active
voice: eg. 'Click Options to open the printer menu' instead of
'When the Options button is clicked on, the printer menu will open'
10) Break all modules into chapters. Frame each chapter with
a chapter slide. It's also a good idea to show the Index page
before each chapter slide with a progress indicator (I use an
animated arrow to flash next to the name of the next chapter), I
use a start button rather a 'next' button for the start of each
chapter. You should always have a module overview with the purpose
of the course and a summary slide which states what was covered and
they have complete the module.
11) Put a transparent click button somewhere on each slide.
Set the properties of the click box to take the learner back to the
start of the current chapter by pressing F2. This allows them to
jump back to the start of their chapter at any time. You can also
do a similar thing on the index pages which jumps them to another
chapter.
12) Recording video capture: best to do it at normal speed
and be concious of where your mouse is. Minimise your clicks. Most
people (until they start working with captivate) are sloppy with
their mouse and you end up with lots of unnecessarily slides that
you have to delete out. The speed will default to how you recorded
it and this will reduce the amount of time you spend on changing
timings.
13) Captions: My rule of thumb is minimum of 4 seconds - and
longer depending on the amount of words. Eg. Click 'Print Preview'
is 4 seconds, a paragraph is longer. If you creating knowledge
based modules, make the timing long (eg. 2-3 minutes) and put in a
next button so that the learner can click when they are ready.
Also, narration means the slides will normally be slightly longer.
14) Be creative: Capitvate is desk bound. There are some
learners that just don't respond no matter how interactive
Captivate can be. Incorporate non-captivate and desk free
activities. Eg. As part of our OHS module, there is an activity
where the learner has to print off the floor plan, and then wander
around the floor marking on th emap key items such as: fire exits;
first aid kit, broom and mop cupboard, stationary cupboard, etc.
Good luck!

Tips n Tricks/Best Practices for integrating iPhone, iPad and MacBook Pro

My wife just purchased an iPhone, iPad and Macbook Pro for her non profit consulting business and I was wondering if a tips and tricks or best practices for efficiently and productively integrating these devices exists?

http://www.apple.com/icloud/

Best practices for development / production environments

Our current scenario:
We have one production database server containing the APEX development install, plus all production data.
We have one development server that is cloned nightly (via RMAN duplicate) from production. It therefore also contains a full APEX development environment, and all our production data, albeit 1 day old.
Our desired scenario:
We want to convert the production database to a runtime only environment.
We want to be able to develop in the test environment, but since this is an RMAN duplicated database, every night the runtime APEX will overlay it, and the production versions of the apps will overlay. However, we still want to have up to date data against which to develop.
Questions: What is best practice for this sort of thing? We've considered a couple options:
1.) Find a way to clone the database (RMAN or something else), that will leave the existing APEX environment intact? If such is doable, we can modify our nightly refresh procedure to refresh the data, but not APEX.
2.) Move apex (in both prod and dev environments) to a separate database containing only APEX, and use DBLINKS to point to the data in both cases. The nightly refresh would only refresh the data and the APEX database would be unaffected. This would require rewriting all apps to use DBLINKS though, as well as requiring a change to the code when moving to production (i.e. modify the DBLINK to the production value)
3.) Require the developers to export their apps when done for the day, and reimport the following morning. This would leave the RMAN duplication process unchanged, and would add a manual step which the developers loath.
We basically have two mutually exclusive requirements - refresh the database nightly for the sake of fresh data, but don't refresh the database ever for the sake of the APEX environment.
Again, any suggestions on best practices would be helpful.
Thanks,
Bill Johnson

Bill,
To clarify, you do have the ability to export/import, happily, at the application level. The issue is that if you have an application that consist of more than a couple of pages, you will find yourself in a situation where changes to page 3 are tested and ready but, changes to pages 2, 5 and 6 are still in various stages of development. You will need to get the change for page 5 in to resolve a critical production issue. How do you do this without sending pages 2, 5 and 6 in their current state if you have to move the application all at once??? The issue is that you absolutely are going to need to version control at the page level, not at the application level.
Moreover, the only supported way of exporting items is via the GUI. While practically everyone doing serious APEX development has gone on to either PL/SQL or Utility hacks, Oracle still will not release a supported method for doing this. I have no idea why this would be...maybe one of the developers would care to comment on the matter. Obviously, if you want to automate, you will have to accept this caveat.
As to which version of the backend source control tool you use, the short answer is that it really doesn't matter. As far as the VC system is concerned, you APEX exports are simply files. Some versioning systems allow promotion of code through various SDLC stages. I am not sure about GIT in particular but, if it doesn't support this directly, you could always mimic the behavior with multiple repositories. Taht is, create a development repository into which you automatically update via exports every night. Whenever particular changes are promoted to production, you can at that time export form the development repository and into the production. You could, of course, create as many of these "stops" as necessary to mirror your shop's SDLC stages, e.g. dev, qa, intergation, staging, production etc.
-Joe
Edited by: Joe Upshaw on Feb 5, 2013 10:31 AM

Best practice for a deplomyent (EAR containing WAR/EJB) in a productive environment

Hi there,
I'm looking for some hints regarding to the best practice deployment in a productive
environment (currently we are not using a WLS-cluster);
We are using ANT for buildung, packaging and (dynamic) deployment (via weblogic.Deployer)
on the development environment and this works fine (in the meantime);
For my point of view, I would like to prefere this kind of Deploment not only
for the development, also for the productive system.
But I found some hints in some books, and this guys prefere the static deployment
for the p-system.
My question now:
Could anybody provide me with some links to some whitepapers regarding best practice
for a deployment into a p-system ??
What is your experiance with the new two-phase-deploment coming up with WLS 7.0
Is it really a good idea to use the static deployment (what is the advantage of
this kind of deployment ???
THX in advanced
-Martin

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Best Practice for Production environment

Hello everyone,
can someone share the best practice for a production environment? or is there a SAP standard best practice to follow in a Production landscape?
i understand there are Best practices available for Implementation , Migration and upgrade. But, i was unable to find one for productive landscape
thanks.

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Best Practice for Production IDM setup

Hi, what is the best practice for setting up prodcution IDM:
1. Connect IDM prod to ECC DEV,QA and Prod or
2. Connect IDM prod to ECC prod only and Connect IDM dev to ECC Dev and QA.
Please also specify pros and cons for both options if possible.
Thanks in advance,
Farhan

We run our IDM installation as per your option 2 (Prod and non-prod on separate instances)
We use HCM for the source of truth in production and have a strict policy regarding not allowing non HCM based user accounts. HCM creates the SU01 record and details are downloaded to IDM through the LDAP extract. Access is provision based on Roles attached to the HCM Position in IDM. In Dev/test/uat we create user logins in IDM and push the details out.
Our thinking was that we definitely needed a testing environment for development and patch testing, and it needs to be separate to production. It was also ideal to use this second environment for dev/test/uat since we are in the middle of a major SAP project rollout and are creating hundreds of test and training users with various roles and prefer to keep this out of a production instance.
Lately we also created a sandpit environment since I found that I could not do destructive testing or development in the dev/test/uat instance because we were becoming reliant on this environment being available. Almost a second production instance - since we also set the policy that all changes are made through IDM and no direct SU01 changes are permitted.
Have a close look at your usage requirements before deciding which structure works best for you.

Best-practice for Catalog Views ? :|

Hello community,
A best practice question:
The situtation: I have several product categories (110), several items in those categories (4000) and 300 end-users. I would like to know which is the best practice for segment the catalog. I mean, some users should only see categories 10,20 & 30. Other users only category 80, etc. The problem is how can I implement this ?
My first idea is:
1. Create 110 Procurement Catalogs (1 for every prod.category). Each catalog should contain only its product category.
2. Assign in my Org Model, in a user-level all the "catalogs" that the user should access.
Do you have any idea in order to improve this ?
Saludos desde Mexico,
Diego

Hi,
Your way of doing will work, but you'll get maintenance issues (to many catalogs, and catalog link to maintain for each user).
The other way is to built your views in CCM, and assign these views to the users, either on the roles (PFCG) or on the user (SU01). The problem is that with CCM 1.0 this is limitated, cause you'll have to assign one by one the items to each view (no dynamic or mass processes), it has been enhanced in CCM 2.0.
My advice:
-Challenge your customer about views, and try to limit the number of views, with for example strategic and non strategic
-With CCM 1.0 stick to the procurement catalogs, or implement BADIs to assign items to the views (I experienced it, it works, but is quite difficult), but with a limitated number of views
Good luck.
Vadim

Best Practice for Securing Web Services in the BPEL Workflow

What is the best practice for securing web services which are part of a larger service (a business process) and are defined through BPEL?
They are all deployed on the same oracle application server.
Defining agent for each?
Gateway for all?
BPEL security extension?
The top level service that is defined as business process is secure itself through OWSM and username and passwords, but what is the best practice for security establishment for each low level services?
Regards
Farbod

It doesnt matter whether the service is invoked as part of your larger process or not, if it is performing any business critical operation then it should be secured.
The idea of SOA / designing services is to have the services available so that it can be orchestrated as part of any other business process.
Today you may have secured your parent services and tomorrow you could come up with a new service which may use one of the existing lower level services.
If all the services are in one Application server you can make the configuration/development environment lot easier by securing them using the Gateway.
Typical probelm with any gateway architecture is that the service is available without any security enforcement when accessed directly.
You can enforce rules at your network layer to allow access to the App server only from Gateway.
When you have the liberty to use OWSM or any other WS-Security products, i would stay away from any extensions. Two things to consider
The next BPEL developer in your project may not be aware of Security extensions
Centralizing Security enforcement will make your development and security operations as loosely coupled and addresses scalability.
Thanks
Ram

Best Practices for SRM Installation !!

Hi
can someone share the best Practices for SRM Installation ?
What is the typical timeframe to install SRM on development server and as well as on the Production server ?
Appericiate the responses
Thanks,
Arvind

Hi
I don't know whether this will help you.
See these links as well.
<b>http://help.sap.com/bp_epv170/EP_US/HTML/Portals_intro.htm
http://help.sap.com/bp_scmv150/index.htm
http://help.sap.com/bp_biv170/index.htm
http://help.sap.com/bp_crmv250/CRM_DE/index.htm</b>
Hope this will help.
Please reward suitable points.
Regards
- Atul

Best Practices for Workshop IDE (Development Workstation Setup)

Is there any Oracle documentation that describes best practices for setting up Workshop and developing on a workstation that includes Oracle's ODSI, OSB, Portal, and WLI? We are using all these products on a weblogic server for each developer's machine and experiencing performance and reliability issues. What's the optimal way to use these products on a developer's workstation. Thanks.

Hi,
Currently you dont see such best practice site with in workshop.
but you can verify most issues from doc.
http://docs.oracle.com/cd/E13224_01/wlw/docs103/
if you need any further assistance let me know.
Regards,
Kal

Best practices for promotions to production

Similar Messages

Maybe you are looking for