Sap portal : Navigation link not appearing

Recently problem occurred where the navigation links seems to be missing

workaround:
my-career area appeared after removing setting in roles and workset; 


1.login as admin; goto 

Portal content
content provided y sap
end user content
employee self service
custom content
my career

workset mycareer ->  select properties -> goto leaf folder and click no;


2. .login as admin; goto 

Portal content
content provided y sap
end user content
employee self service
custom content
roles->  ESS -> click on the workset my career inside roles and select properties ->

goto leaf folder and click no


Conclusion make sure both are sync-ed
Last and not least if you want fast results
goto system administrator
-> navigation -> navigation cached and clear everything

Portal Graphic Rendering problem

Recently we got an error on the mss giving suer slow respond
and in MSS - Overview - workoverview [attandance overview]
it shows this error 

This problem is normally got to do with the
IGS - internet graphic service


please do refer to the link it will teach you step by step to fix or pin point the error.
http://help.sap.com/saphelp_nwce10/helpdata/en/45/f15ed044c741b2e10000000a11466f/content.htm


in r3 use the transaction code "sigs" to check on it.
you can even see the process in rz20..

Well if all this while there wasnt any error and suddenly it gave out this error. The quickest way is to reboot th whole SAP system.

http://community.altiusconsulting.com/blogs/jamesrothwell/archive/2008/12/02/branding-your-sap-bw7-0-portal-and-web-templates-with-portal-themes.aspx

How to transport SAP portal Theme

Create a transport package by going to SystemAdmin->Transport->Transport Package->export.After creating a transport package add Your Theme,defualt framework to the package created and transport it.



Source taken from sdn website
https://forums.sdn.sap.com/thread.jspa?threadID=271644&tstart=0

The Little SE80 of Horrors

REad this! Good for us SE80-ER
The past Three entries today was given by my colleague CYC

This is really true....

Source
Ps: this is not what i write but from the author above which i put into the blog.
Below is 100% quoted from the source

Random ramblings of an obsolete programmer

No - I don't think that people are getting dumber as time progresses. But I do think that we are some how not helping the next generation of developers to improve up on what the people who went before them left behind. And this includes ABAP developers.  When I say "we" - I specifically exclude the smart ones who didn't jump into the holes and avoided the temptations. So all the good and smart people - the stuff below is not about you, and don't get offended.

 

Some of you might know that I started my SAP career as an ABAP developer. I have no claims to have been in the league of Thomas Jung or Rich Heilman :) . But I believe I was an above-average programmer. As my career progressed, I moved on to other things - BW, SEM, SD, CRM and so on, but never did leave the "dark side". And I have been actively mentoring several consultants over the past years, many of whom have ABAP as their core skill. It is my discussions with my mentees that primarily prompted me to write this blog.

 

In my first SAP project - the server had 500 GB hard disk, and 1 GB RAM. This supported 25 users in a small manufacturng company. The desktops all had 32MB t0 64MB RAM, and something older than the pentium processor. This meant we had to think really hard about the code we created - anything inefficient would never get past the QA box. And we did not have a QA team - the developers could see for themselves when their code was terrible - and would go right back to re-designing the code. There was no code-inspector in the workbench either :) . Of course traces etc were available, and well utilized. Our team leads used to have competitions on who in their team would write the most efficient programs.

 

Most of us knew some other language before we learnt ABAP. And amongst my peer group at the time - the most common "first language" was C, and Dennis Ritchie was (and still is) God. One of the biggest gripes we had about ABAP was that it did not give us the flexibility that C gave (countless arguments about sort algorithms in C and then a simple SORT command in ABAP). This background in C ( the other popular one was LISP, which unfortunately I never got to learn), and the hardware limitations must have played a significant role in how our coding styles evolved.

 

ABAP programs mostly followed a procedural paradigm when I started. And then at some point, the OO paradigm started to kick in. By this time, I had started to lead ABAP teams. It was an awfully difficult time for developers to adapt - and people developed a hybrid style. If you had to maintain programs that were developed in this era - my sympathies are with you. Coincidentally, processors had become more powerful, and memory had become cheaper (though not as much as it is today). As a consequence - we had much more powerful servers and PCs, and as a result, we did not have to worry too much about algorithm efficiencies to get the same performance as before.

 

I did not realize the harm that had set on us, at the time - we just got habituated to write mediocre code. As moore's law kept proving itself as time progressed, we started going more and more backward in programming. The pathetic part is that we never realized this in time. Since we did not have to worry about quality to the extreme extent like before, we used the time to develop more and more programs and functionality. Dreadful as it might sound - quantity won over quality. We even slacked on peer reviews of code, that used to be second nature for us not that long ago. I believe that this also partly contributed to a decrease in the standard of training that new developers recieved. You no longer needed an internship to start your SAP career - a 6 week training course became a very acceptable entry criteria for developers.

 

Evidently, I was not the only team lead who realized this. And voila - SAP projects all over started having QA teams who started inspecting code formally. A lot of clients with big SAP footprint started having inhouse QA teams for it, and consulting companies started selling this as a service. I do believe that this helped some - things did get a bit better, but not for long.  If you do anything en-masse, you have to standardize. And QA process became standardized too - and along with the good, came the bad. A lot of QA people I have come to know,  barring a few exceptions, just go through a checklist mechanically, and do not take the time to understand the actual algorithm and offer meaningful suggestions. This is something a developer can do for his own code - and I am not sure if this type of QA really adds a lot of incrememental value.

 

I have been debating the solution for these issues for a while now - and here are some of the things we seem to get some consensus on.

 

1. Don't just train new crop of developers in just ABAP - also educate them in good software engineering practices. It might also be a good idea to train them in a second language if they don't know it by the time they learn ABAP. It is hard to improve when you have nothing to compare against :)

 

2. Have better benchmarks - somehow show the developer how much better his programs could be. ( A friend of mine, if he has his way, would like to have a QA box which is much less powerful than production for developers to get their code better).

 

3. Have a compulsory internship with a good senior developer, before some one is allowed to work independently as a developer.

 

4. Encourage senior developers to take turns and lead the QA teams, and don't let any one be in QA role for very long.

 

 5. Encourage debates on programming practices - do not blindly follow something without getting a solid understanding of the arguments for and against. For example -  Offlate, I have not seen many developers who argue against OO as a development paradigm. Infact, the prevailing sentiment is very much against the old procedural paradigms. However, I have heard and read several interesting conversations where people tore the OO paradigm to pieces. It is less important on which side of the debate you are positioned - the important part is to participate, and expand your thinking.

 

I have one other area that is close to my heart, that I wanted to bring up here - the maintainability of the code we develop. However, I guess I have over stayed the welcome for one web log, so I will defer that to another day.

 

So, what do you folks think?

SAP Naming convention....

Hmm all this while I was wondering the REAL naming convention.... but alas.
my colleague CYC huhu as usual provided.....
as below
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/15304