Portal System Transport (Best Practice)

Hello,
We have DEV, QA and PRD landscape. We have created systems that connect to backend ECC systems. Since the DEV and QA ECC system has one application server, we have created a portal system of type singe application server in the DEV Portal that points to DEV ECC system. Subsequently we have transported this portal system to QA portal and make it point to QA ECC.
Now the Prd ECC systems is of type load balancing with multiple servers. The portal system that connects to Prd ECC system should also be of type Load Balancing. Now we cannot transport the QA portal system that connects to QA ECC system to prd since its of type Single Application Server.
What will be the best strategy to create the portal system in prd portal that points to PRD ECC.
1. Create the portal system freshly in Prd system of type Load Ballancing. Does it adhere to the best practise approach that suggest Not to Create anyting in prd system directly.
OR
2, Is there any other way that should I follow to make sure that Best Practices for Portal Dvelepment is followed.
Regards
Deb

I don't find it useful to transport system objects so I make them manually.

Similar Messages

Transport Best Practices - Cumulative Transports

Hi All,
    I am looking for a some sort of authoritative guide from SAP on ECC Transport Best Practices, especially around merging/combining/accumulating multiple transports into fewer ones. We are a very large project, but we haven't figured out the CVSs like ChaRm so we still deal with individual transports.
The reason I am asking this is that we some development leads on our project that insist that ALL transports that leave Development system must be imported into Production. They claim this the SAP best practice. An SAP consulting review of our system also left a vague note that "We are orphaning transports". This could mean that 1. either we are not importing all the stuff that leaves Dev system 2. or we are not keeping track of our code changes across all environments. Proponents of "All transports must get to PRD" are interpreting this as "1".
I have my team cumulate transport for subsequent changes into newer transport and only take the newest Transport to Production. The continuous rolling of old Transport into new one using SE01 "Include Objects" options ensures that all changes part of current development are in a single TR. Fewer transports mean fewer housekeeping across all systems, and less chances of something going out of sequence or missed out. This is for Workbench Transports only. I understand Config transports could get a little tricky with rolling in.
If you can't point me to a link, what is your take on "Send everything to Prod" vs. "Combine changes into fewer Transports"? I can't think of any software packaging methodology that suggests putting everything, including some junk/crap, into production build. I have looked at SAP enhancement packs, SPS, and Notes. I haven't found any evidence of SAP including older buggy code in what it releases to its customers.
Thank you all!

Jānis, Christian,
    I think we are all on the same page. Let me clarify my specific scenario a little bit more.
We are about 15 ABAP developers team, for production support. We don't do huge changes. Our code updates are mostly limited to a handful of objects (average 2 - 5). We often have multiple iterations to same objects. For large scale development objects, this approach may not work very well. Those should really utilize SolMan or other CVS tools.
Here is How I have my team putting together final transport.
step 1. Change is done to object X. Transport #1 created and released after standard checks.
step 2. More change is needed for object X. Transport #2 Started. Transport #1 is brought in using SE01 include objects at the main task. Changed objects are in lower tasks. This way, I can tell what was brought over, and what really changed this time. Releases of the Transport #2 inspects all objects and insures all objects from #1 are included in #2, and that there are no other changes between #1 and #2 to any of the objects. This is very easy check mostly from Version History.
Step 3. More changes needed to object X and Y. Transport #3 started. Transport #2 brought in at main task. Same check from Step 2 is done to ensure no other changes exist.
step 4....6. Step 6 ended at Transport #6. All changes verified in QA system.
Only the Transport #6 needs to be sent to Production since previous Transports 1 to 5 were rolled into #6.
Jānis, the deletions will be covered automatically just like standard SAP. No special manual steps needed.
Christian,
   The transport of copies works in similar way. Only thing different is that the Main/cumulative transport is released at very last, possibly after QA tests have been confirmed.
I had thought about doing Copies vs. cumulative. I preferred to go with having Transport in QA already at the time of approval. I would have hard time explaining to our client why a Transport was released out of Dev After all tests were done and signed off.
However, the Copies have advantage that intermediate versions or parallel changes of same objects are easily recognized upfront vs. us having to check each transport before release.
Jānis, the "copies of Transport" also creates extra versions in version history just like manually adding objects in a transport.
My quick analysis between copies and cumulative only came with one different that 'copies' have a different flag/attribute in Table E070. I am sure the flag means something to SAP, but for versioning history, it makes no differences.
Regardless of if I cumulate or not, based on your experiences, have you come across notion that everything that leaves Dev must get to PRD as SAP Best Practice? What would your reply be if someone insists that is the only way to move code to production?

Look For Transport Best Practices

Hi,
I am looking for transport best practices, so please answer the following questions on how your place of business handles :
1. If an object is modified in development and you decide that you you do not wish to move the modifications forward - Do you;
    a. delete the transport and release the locks
    b. create a corrective transport and move the transport through production
    c. release the transport and never import it into the next system
    d. something different : (Please explain)
2. If a transport is imported into QA and then you decide never to move it to production, do you:
    a. delete the transport and release the locks
    b. create a corrective transport and move the transport through production
    c. release the transport and never import it into the next system
    d. something different : (Please explain)
Thanks Rob
[email protected]

I was always taught never to delete a transport. The changes should be reversed in the same transport and moved forward or released and the corrective transport moved forward in the same import queue.
If the transport goes to QAS then it needs to move to production. A corrective transport should be imported into production in the same queue.
I am sure you can get 20 different answers on this, but this is my policy.

Portal 8.1 best practices document.

Hi All,
Is there any document on Portal 8.1 best practices standard document?
If yes, can somebody send me the same OR point me to appropriate URL?
Thanks,
Prashanth Bhat.

Hi,
http://edocs.bea.com is the entry point to docs. Try these documents as a start
On the URL below is several links to various useful documents.
http://e-docs.bea.com/wlp/docs81/index.html
- Anders M.

Development System Backup - Best Practice / Policy for offsite backups

Hi, I have not found any recommendations from SAP on best practices/recommendations on backing up Development systems offsite and so would appreciate some input on what policies other companies have for backing up Development systems. We continuously make enhancements to our SAP systems and perform daily backups; however, we do not send any Development system backups offsite which I feel is a risk (losing development work, losing transport & change logs...).
Does anyone know whether SAP have any recommendations on backuping up Development systems offsite? What policies does your company have?
Thanks,
Thomas

Thomas,
Your question does not mention consideration of both sides of the equation - you have mentioned the risk only. What about the incremental cost of frequent backups stored offsite? Shouldn't the question be how the 'frequent backup' cost matches up with the risk cost?
I have never worked on an SAP system where the developers had so much unique work in progress that they could not reproduce their efforts in an acceptable amount of time, at a acceptable cost. There is typically nothing in dev that is so valuable as to be irreplaceable (unlike production, where the loss of 'yesterday's' data is extremely costly). Given the frequency that an offsite dev backup is actually required for a restore (seldom), and given that the value of the daily backed-up data is already so low, the actual risk cost is virtually zero.
I have never seen SAP publish a 'best practice' in this area. Every business is different; and I don't see how SAP could possibly make a meaningful recommendation that would fit yours. In your business, the risk (the pro-rata cost of infrequently needing to use offsite storage to replace or rebuild 'lost' low cost development work) may in fact outweigh the ongoing incremental costs of creating and maintaining offsite daily recovery media. Your company will have to perform that calculation to make the business decision. I personally have never seen a situation where daily offsite backup storage of dev was even close to making any kind of economic sense.
Best Regards,
DB49

Portal server deployment best practices

anyone out there knows what is the right way to deply portal server into production environment instead of manually copying all the folders and run the nessarily commands? Is there a better way to deploy portal server? Any best practices that i should follow for deploying portal server?

From the above what I understood is you would like to transfer your existing portal server configuration to the new one. I don't think there is an easy method to do it.
One way You can do is by taking the "ldif " back up from the existing portal server.
For that first you have to install the portal server in the new box and then take back up of existing portal server using
# /opt/netscape/directory4/slapd-<host>/ldif2db /tmp/profile.ldif
edit the "/tmp/profile.ldif " file and modify <hostname> and <Domain name> with the new system values.
copy this file to the new server using
# /opt/netscape/directory4/slapd-<host>/ldif2db -i /tmp/backdb.ldif
and also copy the file "slapd.user_at.conf " under /opt/netscape/directory4/slapd-<hostname>/config to the new system.
Restarting the server makes you to access the portal server with the confguration of the old one.

Site System Roles - Best Practices

Hi all -
I was wondering if there wwere any best practice recommendations for how to configure Site System Roles? We had a vendor come onsite and setup our environment and without going into a lot of detail on why, I wasn't able to work with the vendor. I am trying
to understand why they did certain things after the fact.
For scoping purposes we have about 12,000 clients, and this how our environment was setup:
SERVERA - Site Server, Management Point
SERVERB - Management Point, Software Update Point
SERVERC - Asset Intelligence Synchronization Point, Application Catalog Web Service Point, Application Catalog Website Point, Fallback Status Point, Software Update Point
SERVERD - Distribution Point (we will add more DPs later)
SERVERE - Distribution Point (we will add more DPs later)
SERVERF - Reporting Services Point
The rest is dedicated to our SQL cluster.
I was wondering if this seems like a good setup, and had a few specific questions:
Our Site Server is also a Management Point. We have a second Management Point as well, but I was curious if that was best practice?
Should our Fallback Status Point be a Distribution Point?
I really appreciate any help on this.

The FSP role has nothing to do with the 'Allow
fallback source location for content' on the DP.
http://technet.microsoft.com/en-us/library/gg681976.aspx
http://blogs.technet.com/b/cmpfekevin/archive/2013/03/05/what-is-fallback-and-what-does-it-mean.aspx
Benoit Lecours | Blog: System Center Dudes

Portal db provider(best practice)

Best practice question here. If I wanted to create a few db portlets(suggestions/questions) is there already an existing portal db provider/schema that I should add them to? Or is it best to simply create a schema and db provider?

That is an interesting question, we created our own schemas for each of the portal sites we have, so basically custom made providers for all portlets used in those portals.

Manage Portal data ? best practice type thing

Hello,
I am looking how best do set up a Portal System on Production, in particular a
good process to back-up and re-create an Portal systems.
I list some possibilities below. Does anyone know if this is how it is typically
done ? Does this cover all data which should be backed up / migrated ?
thanks!
1- 'Entitlements' data. As far as I know, this is stored in the embedded LDAP.
Can this be extracted ?
2- DataSynch data.
DataSynch web application.
extract with ftp-like command
upload as jar file
3- Users and Groups.
Export to a dat file. (Suddenly I forget how to do this, though think I saw it
somewhere).

Okey, and then using a RFC call from the webdynpro application to fetch data from the sap database?
This answered my question:
Best regards
Øyvind Isaksen

Transports: Best practice in reversing old transports not moved to PRD

Hello Guru's,
I have a lot of old transports moved from DEV to QAS that don't work or are irrelevant that need to be reversed. These transports were made by a consultant no longer with the company and there is no documentation of what was changed.
What is the best method in reversing these changes?
I appreciate your help!

Next time, don't ask for the best practice. You would likely get more response if you simply ask "What would you do..?"
Rob

System Emails Best Practices

Hi, I need a professional recommendation on what is the best practice when dealing with our customers system emails.
I'm asking this because BC create all the workflows and system emails with the partner details, which I find really ridiculous.
Then you have to go and change all of these emails to the client email. I realised lately that BC have a default email setting for system emails. I changed all these to my client email address, but still I'm receiving inquiry and they are getting my name somehow.
This is very embarassing and I hate to see it happening again. Can someone please help me with what procedures I need to take to avoid this.
As partners do we usually leave ourselves as administrators and receiving every workflow our client receives? What if you have 100 clients?
Shouldnt BC add a "BC Partner" to users? like a super administrator in Joomla instead of being together with other administrator?
Thanks
Michel

Hi Michel,
The system is a framework in terms of site elements, so of course will have default information which you can choose to change or not (such as workflows).
In terms of forms and notification emails:
- Make sure you update forms notifications and emails
- Make sure you update notification emails for mailing lists
- Make sure the mass change for system emails is applied and you choose the correct template if you wish to for each one.
For Workflows:
- System comes with some basic ones and of course you can build your own.
- Normally the thing you will do is modify or add your clients to "users" or their own role such as "busines name admin" for example. You may have multiple users and for them to have multiple roles. Under the new interface permisions control what they see and have access too.
- Workflows are set to you for testing mainly, allowing you to get workflows and email notifications as you develop to see how things are shaping up and are working.
- Go into workflows and change them so that emails / txts / steps go to the right people.
You can find more information if you need to on workflows in the knowledgebase if you not gone through them already.

Portal and Portlet best practice...

Hello All,
We're just at the start of next gen Portal project. We've selected Oracle Portal for our solution, jdev, the whole thing.
Last year an application was developed in our organization using Oracle Portal. In this application, the user interface is divided up into many portlets. i.e. the menu bar is it's own portlet, the content area is multiple portlet depending on what part of the application you're in.
My question is, is this considered the best pratice for developing interoperable portals? We will have several differing web applications consolidated into one portal interface when this process is over.
However, that said, does it make sense to seperate all of a site's functionality out into atonomous portlets?
Or should a web application, with workflow in this case be consolidated into one portlet, that is configurable?

Hi!
I don't think that complex applications should be developed in portlet manner.
Portlets are very simple small applications.
You can place them anywere on your portal.
My opinion is if you have to build a complex applications, then it should be implemented with JHeadstart or some other framework.
You can place the login link of this application on Portal that opens a new window.

System.out vs. System.err -- best practices?

When I catch an exception, where is the best place to write the stack trace, etc? Should I write it to System.out or System.err?
Thanks,
Curt

If you call printStackTrace() it will by default print to the to the standard error stream.
But really you should look at log4j.

SPARC system asset - best practice

Hello,
Is it possible to have OS asset and Service Processor asset for a single host system as one asset subtree?
(Platform is T1000, EM is 12.1.1.0.0)

I don't find it useful to transport system objects so I make them manually.

System Management Best Practice Questions

I help out with IT at a small fire department, town is around 3,000 people. They have about 10 PCs. The only time I really do anything is when someone has a question, or points out a problem. Everything is in place, and works well. However, is there anything
I should be regularly checking on? We have the usual in place: Anti-virus on all PCs, Windows Updates are automatic, all PCs have passwords, Wi-Fi has a password, etc.

AS i know addUser(User user){ ... } is much more useful for several reasons:
1.Its object oriented
2.its easy to write , because if Object has many parameters its very painful to write method with comma seperated parameters

Portal System Transport (Best Practice)

Similar Messages

Maybe you are looking for