Mostly SAP related…
SAP
The Stapler Interface
Jun 15th
Despite the multitude of options available for loading data into SAP, it seems the stapler still remains popular…
Trust your ABAP Consultant
Oct 28th
I recently read a very interesting post by Martin Ceronio that explains an innovative way of gaining shell access to any SAP system.
Obviously, Basis and Security consultants all over will have a fit when they realise this is possible on their precious SAP systems. I must admit though, this is so easy that I am not 100% comfortable with this hole.
But, In order to exploit this you do need access to an SAP system and a fair amount of knowledge of how SAP works …and sufficient authorization.
This brings me to something that has been bothering me lately, which is customers need to trust the consultants they give access to their systems, especially ABAP consultants as they no more about the internals of SAP than anyone else.
The latest trend is to lock down authorizations in development systems to the point where consultants are unable to perform their work and there is always doubt as to whether the problem is code related or authorization related. I completely support the full lock down of Quality Assurance and Production Systems, but is it really necessary in Development?
The moment you give a consultant debug with variable change authorization(which ABAP consultants must have in development), virtually any check can be bypassed (you can even grant yourself SAP_ALL and a Developer Key).
The other major threat is ABAP developers writing malicious programs and slipping them into production under the radar.
In my view draconian restrictions in development systems frustrates your consultants and leads to a real increase in development time. The assumptions made by the implemter of these authorizations must be(maybe a bit harsh):
- The consultants cannot be trusted to act responsibility
- They are too stupid to find their way around all the restrictions
There is a lighter side to this though and that involves phoning the authorization consultant at 2:00 AM for that transaction code you really need now to the fix problem(and going to bed and booking a delay against him if he doesn’t answer).
Sending mail from SAP
Sep 29th
The ability to send and receive e-mail is critical to any CRM system. Sending e-mail from SAP is really simple, but battling the network administrators can sometimes be challenge.
In this post I want to show how to technically configure sending of mail from a SAP Server running Linux with Postfix. I have not used Microsoft Exchange(so won’t try to describe here), but the concept is the same. In future, I will describe the receiving of mail into SAP and the configuration required to send and receive CRM WebClient mail.
With WAS 6.10 the SAP system contains its own SMTP Server. In theory the SAP SMTP Server can be used to send and receive mail on the Internet, but in practice you probably don’t want to do this due to following reasons:
- Exposing your SAP System directly to the Internet is a security risk.
- Normally you only want 1 or 2 addresses to be used by SAP and these must use the corporate domain. You don’t want all your corporate mail to come into SAP.
- The standard SMTP port required for sending Internet mail is 25. On Unix systems, root privileges is required to start services that listen on port 25. The SAP System runs with normal user rights, therefore it can’t start the SMTP server on port 25. Unless you use icmbnd.
The receiving of mail will be tackled later, but if you ever want to receive mail you must configure your sending addresses in such a way that receiving will be possible in future. Therefore, I need to create an internal mail domain(I don’t really need to do this for sending, but its the slick way).
The diagram below describes the end state we want to achieve.
Postfix Setup
Install Postfix or another SMTP Server on the SAP Server or another machine in the network. The SMTP server will run on Port 25 and will relay the mail from SAP to the world. Typically you would reuse your existing corporate SMTP server.
Importantly, you have to allow the SAP Server to relay mail via Postfix. This is done by adding the IP address(e.g. 10.20.30.40) of the SAP Server to the mynetworks spefication in the main.cf file(located in /etc/postfix on suse).
mynetworks = 10.20.30.40, [rest of what was there before]
Also, SAP will send the mail from crm@sap.company.local, but we want to change that to crm@company.com. You achieve this by maintaining a mapping in the sender_canonical file in /etc/postfix. The line below shows the entry to be maintained.
@sap.company.local @company.com
Once the above change has been made the postmap command below must be run in configuration directory to create the lookup file./etc/postfix> postmap sender_canonical
SAP Setup
Here all the setup is done in transaction /nSCOT. You must point the SMTP node to the Postfix server and activate it. Double click on the smtp node as shown below.
The 2 important settings to maintain is Mail Host(the IP address of your Postfix server) and the node in use tick.
You must also maintain the Default Mail domain(very important) under Settings->Default Domain to crm@sap.company.local. The nasty way to configure this is to simply send mail from crm@company.com, in which case you don’t need the Postfix sender mapping.
You must now schedule a periodic job to send e-mail from SAP. This can be done by going to Settings->Send Jobs. In the popup select “Schedule Job for INT”, the pop up below will allow you to schedule this job. E-mails will be sent periodically every time this job runs.
Finally, make sure that you have an e-mail address maintained(e.g. user@sap.company.local) in transaction SU01 for your user.
You can now goto system->short message and test sending an e-mail to an external address.
SAP Salary Survey SA
Sep 12th
Someone finally performed a Salary Survey that is specific to the South African SAP Market.
You can find the Salary Survey here. Unfortunately, you must register at your own risk to see the results.
The survey makes for good reading and caters for both contractors and permanent employees. It provides data such as average contract rates, contract lengths, and salaries by sap component.
A slight concern I have concerning the survey is that they don’t release the size of the sample used, and I am not 100% convinced the sample is truly representative(I have asked and they’re not telling). Still, I think this is a good thing and hopefully next year’s survey will be better.
Browser Support and SAP CRM
Jun 26th
My default Web Browser is still Internet Explorer 6.0. Not that I particularly like IE 6, I happen to have Firefox, Opera and Safari installed as well.
But, most of my customers still use IE6 and some of their(woefully unpatched) SAP CRM 4.0 and 5.0 IC WebClient Systems still require IE6.
A quick run down on IC WebClient browser support(all the versions support IE6) from the PAM:
- CRM 4.0 – IE7 has been released(11 July 2007) conditionally to the implementation of notes 986254, 1005093 and 981710.
- SAP CRM 5.0 – IE7 is supported with CRM 5.0 Support Pack 10 since 29 July 2007. Also note that the WebClient on IE7 with Vista will only be supported by 30 September 2008!
- SAP CRM 2007 – IE7 support came standard. Also, there is limited support for Firefox 2(This really works, except for the bloody ActiveX controls).
Bottom line, IE6 is still the most trusted and reliable browser to use with the WebClient.
Microsoft released IE7 in October 2006 and it took SAP 9 months to get the WebClient to work with it. It seems IE8 is in beta on its way later this year. Time will tell if the final version 8 will fix the bugs and be as standards compliant as promised.
I don’t think there was anything wrong with SAP developing the IC WebClient(and most of its other BSP Applications) only for IE6 as that was what 99% of its customers were using at the time(I have never seen anything other than IE on a corporate network). However, I imagine SAP spent a truck load of money to make its 3 supported CRM versions work with IE7. Now, IE8 is coming and I wonder how much it will cost SAP to provide IE8 support.
My hope is that SAP realizes that by chasing compatibility for individual browser editions is inefficient. Developing to a standard such as XHTML, wasn’t feasible 2 years ago, but it surely must become the development direction now.
And there is no reason why you shouldn’t be able to display SAP Notes(also a BSP application) with a relatively standards compliant browser such as Opera. By the way, Opera is not supported for any HTMLB based BSP applications, so this is not a CRM specific issue.
A final thought relating to the screenshot above. Why should SAP completely bomb me out if I use an unsupported browser? Why not just run the page and see what happens? Its not as if I am going to log a message about it as the PAM clearly omits Opera as a supported platform.
