Skip to Content
When I grew carrots as a young whippersnapper my Dad would often suggest that I should plant radishes amongst the carrots** because together they grew better than planting them separately. It is with this spirit that I went along to the PHPLondon User Group recently. I believe that SAP has everything to gain and nothing* to loose by embracing open source and PHP in particular.  I went along to the meet up expecting to have a few conversations with some guys who knew more than me and with whom I could share some of my SAP knowledge.   Whilst it is a very informal gathering it was well attended with many coming along for the first time.   There were many different uses of PHP represented. There were emailing apps to frameworks to security apps to route navigation and then some. The age ranged from guys barely out of school to a few grey haired wise old gentlemen.  There were two particular pieces that will interest the scripters amongst us. Marcus Baker has written SimpleTest which is a php testing framework similar to jUnit. Demian Turner has written the Seagull framework which was favourably very favourably alongside the Zend Framework and CakePhp.   I did get a chance to talk with Demian and we had a very interesting conversation around big business and big IT. He mentioned a large company which deployed a large content solution which had a large price tag. The project had some issues and Demian lamented the fact that a PHP solution could have a better result for far less expense and great ROI and lower TCO. The executives probably weren’t aware of this and thought spending more would get them a better enterprise solution. Not always.  Another member who was very keen for some SAP infomation was aware of scripting in a box and Craig’s blog (although I did not determine which one) He complained of being the labelled the ‘web guy’ by the SAP guys in the company.  One other member was very grateful I was there and pumped me for all sorts of information. Others had never even heard of SAP.  All in all it was a great night there was lot of information shared and learned. If you are even in London on the first Thursday in the month, check out where we are meeting  and come along.  *Oh but before I go. I started with carrots and radishes all growing together more effectively together than apart. There are some large applications written in PHP that are starting to grab some headlines. Not least of which is the SUGAR CRM  package. Has SAP got something to loose to SUGAR over its own CRM package? Well that remains to be seen, but what is apparent is that applications like SUGAR are proving that PHP is becoming more enterprise and not just for the ‘web guys’.  ** I have no idea whether planting these vegetables together actually is a good thing to do. It is just a literary devise to make this blog slightly more interesting. For actually horticultural advise please go to a nursery!
To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Andy Silvey
    PHP and other web apps tools are all well and good. However scripting advocates must remember that the more complexity in an IT project the more chance there is of failure.

    Why do large companies buy SAP’s products ?

    One stop shop for software solutions across the whole enterprise. This means one telephone number when things go wrong, this means one software supplier/developer cannot blame the other.

    What is the safest way to ensure success in a SAP implementation/extension project ? Stick as close to the standard as possible.

    If you company has bought the licenses and SAP has the solutions why re-invent the wheel ?

    What happens when it is time to upgrade ? How can you be sure the developers of the wonderful scripted web apps did a thorough design which guarantees on the PHP side and on the ABAP/JAVA[R/3] side zero impact from R/3 side upgrades ?

    Every tool has its place, and in the large organisation, spending a lot of money, it may not look cheaper to the scripting advocate developer to go the big software way but when considering the bigger picture and with experience and hindsight the benefits of sticking to one vendor and as close to standard as possible will become clear.

    Been there, seen it, done it, read the book and bought the T’Shirt, and these days, for anything larger than small departmental apps a policy of sticking as close to SAP standard and SAP tools (ABAP/J2EE) is used.

    All the best,

    Petr.

    (0) 
    1. Community User
      Hi Petr,

      This of course is one of the beauties of Scripting Languages, things such as PHP interface with the “standard” interfaces provided by SAP or with ones custom built by you (meaning the company in question) which means 2 things.

      1) With an upgrade those standard interfaces continue to work – OR there are instructions and notices about them.

      2) If you build something custom such as a ABAP FM  for use by your company you have to deal with it during the upgrade anyway.

      So, and I think this might be were some people are getting the idea behind this support confused is that these types of languages are simply providing an alternative means of working with the system and not a replacement to the standard. By making people more aware of this level of intergration and usage the thought is to only prevent them from doing just what you said “re-invent” the wheel but also to let them know that even though SAP is running 50% of their business they can still integrate and work with the other 50% (if it makes sense of course).

      No one wants to anyone to go away from standards in fact we are encouraging the use of not only standard ABAP FM’s & BAPI’s but also the web services available in the newer releases of NetWeaver.

      Basically, if you have a PHP based intranet and you want to have SAP data there – you have the option without redoing your entire intranet if it does not make sense.

      Craig

      (0) 
      1. Andy Silvey
        Hi Craig,

        granted your points re: upgrading.

        Your line, ‘Basically, if you have a PHP based intranet and you want to have SAP data there – you have the option without redoing your entire intranet if it does not make sense.’

        This is all a question of design.

        If your large enterprise has a PHP based website then hopefully it is one based upon containers and portlets and not glued together with sellotape.

        If it is a PHP based Portal application container supporting Portlet standards then there is no reason to create more interfaces on the PHP side to the SAP based backends.

        Instead, use the tools delivered by SAP for the SAP side of the web enabling, Portal Iviews, BW Web reports, ITS, BSP’s etc and then contain these as a Portlet in your PHP based Portal container.

        Everything is a question of design and architecture, and surely with all of the tools available and today’s internet/intranet/extranet architecture and Portal container standards, surely the best policiy is to keep the SAP web apps on the SAP side using the SAP tools and simply make these ‘pages’, ‘portlets’ available to other web container based applications ?

        We have to think long term, and for sure, from a technologists’ perspective it is exciting interfacing SAP from PHP etc, but for the long term and the benefit of the large organisation it is better to keep the SAP web applications on the SAP side using the SAP technologies available.

        Another perspective, experience has taught me, when interfacing SAP data from Web Apps the best solution is to have the web application server, whether PHP, BEA, Websphere as physically/geographically close to the SAP backend as possible.

        With my solution we are using the SAP Application servers for our processing and rendering of the SAP data web applications and simply delivering the result as a portlet via a PHP Portal solution which can be geographically remote from the SAP system to a user who can be geographically remote from the PHP Portal container. With my solution we have no fear of time outs between the web application and the interrogation of the SAP data. We also have no fear of processing capability as the SAP server is sized and scaled to cope with this.

        With your solution, in our large company, we have a PHP Portal container perhaps running the intranet from California trying to execute BAPI’s on a remote SAP system in Sydney and retrieve data for further processing and rendering, all subscribed by from a user in London. This is messy and prone to all kinds of latency and networking and processing timeouts. Not to mention, how do we split the processing ? We are retrieving the raw data from SAP via a BAPI and then we are rendering it, perhaps into charts and graphs on the PHP side and then publishing it, who is scaling and sizing this ? Do the Intranet team have any idea how much more load our application is going to put on their servers, who is overseeing this globally, who is liasing between all of the teams and who is providing and signing off the budget ?

        Keep it simple, keep it as close to the standard, do everything in SAP using SAP’s tools and deliver to other intranet based applications PHP Portal containers or whatever via a combination of Portlets or at the simplest level IFrames.

        It is easy for a technologist not to see the bigger picture, however, having grown up through the evolution of these technologies and solutions I can tell you I am talking from experience and practicality.

        I agree, PHP is great for knocking up small apps for your team or department, however, for the Fortune 500 company, the best is to stick to the SAP standard and deliver the content to your other web apps using the methods described above.

        All the best and kind regards,

        Petr.

        (0) 
        1. Community User
          Hi Petr,

          Very interesting and I’d love to hear more about it, especially what you have in place and all the dirty little details.

          As for the topic at hand, this is where we realize that either we’re not sending the message out correctly or it’s just not being received correctly.

          Every tool has it’s place, our goal is not to say what that place is, only to offer up the knowledge necessary for one to understand how all the available tools work – nothing more nothing less – it’s up to those of you out there to decide “Does it make sense to do this?” It’s the same question that comes up with every project you start – the community here on SDN simply wants to ensure that as much information as possible is avaialble for making those decisions. This is also why I’d love to hear more about what you are doing – your experience with this would of course add more valuable information to the community at large and to those seeking the information in order to make the best decision about which route they should take.

          Personally my experience differs from yours but then again ones experience differs depending on the projects, company, etc.

          Drop me a line so we can chat a bit more about this and maybe see if we can’T get some of your experiences added to the community knowledge base – we can then also jump off of Nigel’s blog 🙂

          Craig

          (0) 
          1. Andy Silvey
            Hi Craig,

            agree with everything you say there.

            We have to be careful however, when, and with all due respect, when Nigel comments:

            ‘I did get a chance to talk with Demian and we had a very interesting conversation around big business and big IT. He mentioned a large company which deployed a large content solution which had a large price tag. The project had some issues and Demian lamented the fact that a PHP solution could have a better result for far less expense and great ROI and lower TCO. The executives probably weren’t aware of this and thought spending more would get them a better enterprise solution. Not always.’

            This kind of comment is dangerous, because as described above, in the large organisation, what can seem cheaper today to the PHP evangelist, is not necessarily cheaper for the large organisation in the long term.

            I’ll email you.

            All the best,

            Petr.

            (0) 
            1. Community User
              Petr, in all fairness who are you to discount Nigel’s comment? Are you categorically discounting everyone’s experience other than yor own? I just checked your business card to see what I can see about things you mention but all I know is that you are in Germany and that you responded to a few forum posts.

              I’ll wait for your email then we can get things on a better footing and perhaps see what we can do about getting your opinions and observations out there to everyone just like Nigel, Piers, Gregor, Anton and others are doing.

              Craig

              (0) 
            2. Nigel James Post author
              Hey what a great debate has sprung from my little old blog.

              Please excuse my tardy reply and but I have a life and two jobs! SDN has to take the crumbs.

              I don’t really care about the technology. The solution is what matters. I have worked on websites getting SAP content with dcom and asp, with dotNet and asp.net and with JCo and java servlets. What matters is what the client is comfortable with and what their skill base is. One client I was working with wanted to glue a whole bunch of stuff together and we were recomending JCo but due to the internal experience we went with an asp.net solution.
              Another client wanted to distribute a bunch of reports (pdfs) to over 200 ‘clients’. After conversations with the internal network guys we decided a LAMP solution would have been the fastest to deploy. It certainly would have been far cheeper to deploy that getting an external facing SAP portal working, in this particular case, with this particular goal.

              As for the content solution mentioned in the blog it was simply a content solution with no SAP backend in this case. Just content. Mostly words, maybe a few images and the occasional movie file (and probably advertising by the oil container load). This is the sort of stuff that LAMP does really well. Wikipedia anyone?

              I’m not saying PHP is the answer to everything, just trying to raise awareness of what might work if it fits with your business.

              Kind regards,
              Nigel

              (0) 
              1. Andy Silvey
                DISCLAIMER – I am an anonymous User this is not my real name therefore take what I say with a pinch of salt

                Nigel,

                I understand and support what you say here.

                My motivation and fear is the risk of short sighted decisions regarding web applications and SAP integration.

                My goal is that people reading this, who are planning some SAP web enabling project, before choosing a technology most familiar to themselves today will consider the following:

                1, What is their organisations SAP strategy ? How much does their organisation use/rely on SAP ? A lot ? A little ? If a little, what is their organisations plans for SAP in the future ? Increasing their usage, increasing the components they use, increasing their number of Users on SAP ? Who in our organisation is responsible for SAP strategy, Who aligns all departments, all countries and makes sure they are following guidelines when interfacing SAP ? Who ensures one country from our organisation is not duplicating the work of another country ?

                2, Where are the SAP systems ? Are they physically/geographically near the external application servers which are intended to interface SAP ? What are the plans for the location of the SAP systems in the future ? Are there any plans to consolidate all of the SAP servers in the future to a different geographical location ?

                3, The web apps interfacing SAP, are they a pilot ? Are they long term apps whose scope may grow ? Where will the Users, requestors of data be geographically located ? Are the application servers able to support growth in scope and growth in Users and diverse geographic locations of Users ?

                4, The requirement to develop some web applications delivering SAP data ? Does our organisation have BSP/ABAP OO ABAP skills ? Do we have web dyn pro skills ? Do we have Java JCo skills ? Do we have SAP Portal, ITS ? Giving consideration to item 1, should we place more emphasis on increasing these SAP skills ?

                These are some basic questions, I can go on, but I think you get my picture, before choosing the technology solution, give consideration to the above and the direction your organisation is moving in. It will pay dividends in the long run.

                All the best,

                Petr – anonym.

                (0) 
    2. Piers Harding
      Hi Petr,

      I personally take exception to your implied comment that only proprietary software products are well authored, designed, architected, and implemented.  There are plenty of examples out there that prove this FUD wrong, and seeing that you are reluctant to back up your own arguments with hard facts, allow me to counter that.

      Wikipedia – who last I looked had an over 300Gb MySQL DB (this was 18 months ago) is frontended by  PHP – as are all their spin off products.

      Yahoo, Google – even – big users of MySQL and Python.

      Signal37 – Rails.

      To name just a few.

      Now – are you going to tell me they didn’t consider scalability, flexibilty of design, and robustness of architecture?

      Further more – As far as I know – all the scripting language connectors out there use the SAP standard supplied interfaces – that are supported – inorder to achieve their connectivity.  This is namely either the SAP supplied and maintained RFC library, and the RFC-XML/SOAP interfaces – how can they be anything other than compliant, and indeed supported – to that level.

      Lastly – given that you use the statement “don’t reinvent the wheel” you seem to have a feeling that SAP have implemented all the possible tools required  for any given solution – which I doubt that anyone at SAP would ever be prepared to state.  SAP recognise that Scripting Languages have a lot of complementary solutions to offer, with a lot of customer interest to boot, that is why SAP is actively embracing them through support in SDN, and in providing resources to support the developers in the community.

      To me – your arguments are looking a lot like personal prefernce (which is fine) rather than a concrete assessment of the situation.

      Regards,
      Piers Harding.

      (0) 
      1. Andy Silvey
        Piers,

        thank you for your reply.

        I am not discrediting the enterprise capabilities of PHP et al. I am however pointing out that in my opinion, companies which have some kind of SAP strategy will do well to consider their forward looking SAP strategy and try to where possible stick to the standard and standard tools from SAP when extending the applications or making SAP data available to internet and wireless clients.

        I will however question how many companies really have enterprise quality (skilled in object orientation and design patterns) PHP et al developers ?

        Please check what I replied to Nigel re the kind of questions I suggest an organisation/project asks itself before choosing a non-SAP technology for the main engine of a SAP-web-enabling application project.

        At the lowest level, in your experience do you agree or disagree that it is best to keep all SAP related processing as physically close to the SAP backend (or even better on the SAP backend) as possible ? Have you ever had to put waits in your code because the Jco connection has timed out on an application with an R/3 system in one continent and a Java application server in another ?  If you have the skills it is surely better to serve up all content from the WAS ? If you don’t have the skills in your team then think about the 4 or 5 items I listed in the reply to Nigel.

        Kind regards,

        Petr – anonym.

        (0) 
        1. Piers Harding
          Hi Petr –
          So you have shifted your position.
          Now you have a preconceived idea that PHP programmers – indeed all Scripting Language programmers, from your previous comments – are some how likely to be inferrior in quality, just because of the programming language they use.  Why should the average Scripting resource available to an “Enterprise” be any less (or more) capable than that of an ABAP, C, C++, Shell, Cobol, RPG, Fortran … resource?

          The majority of the questions you possited, are architecture independent – you could insert a-another-framework/platfrom-here, and still maintain the relevence, which make the choice of using an SAP offering vs anything else, still open for lively debate on a case by case basis.  The other major issue standing out with them, is that you are automatically assuming that SAP is the largest, or the most important time critical element in a service offering, everytime.  Every single Corporating that I have worked for in the last 18 years, has had at least one other back office system that it has considered either at least as important as SAP, if not more important.  This usualy means that there is a shift of focus on a service solution design, and with that, most likely,  a debate on tools and technologies required, outside an SAP offering.

          You ask the question ” do you agree or disagree that it is best to keep all SAP related processing as physically close to the SAP backend as possible ? “.  This is approximately like asking the question – Should you run with scissors?  And the answer is – how long is a piece of string?

          Regards,
          Piers Harding.

          (0) 
          1. Andy Silvey
            Hi Piers,

            I agree with most of what you say in:

            ‘you could insert a-another-framework/platfrom-here, and still maintain the relevence, which make the choice of using an SAP offering vs anything else, still open for lively debate on a case by case basis. The other major issue standing out with them, is that you are automatically assuming that SAP is the largest, or the most important time critical element in a service offering, everytime’,

            however,

            this is a SAP discussion forum

            and

            this blog is about creating web apps interfacing SAP

            agree though that all of the concerns I have can be applied to any large enterprise wide software.

            You are misunderstanding me I am not discrediting scripting programmers on the whole however I think I can admit to having worked with scripting languages in the past and knocked together web applications without knowing enough about the language to get the best from it as can perhaps other people too – rapid application development and what not. Now as I get older I question the merits of such approaches and especially writing applications which interface software such as SAP in non SAP languages and in separate application servers away from the SAP backend. Hope I am not shifting the discussion again here.

            Regards,

            Petr.

            (0) 
            1. Community User
              Actually Petr, this is a technology, development, and business process, and analyst discussion forum with a theme around SAP technologies. This blog at least my take on the blog is about using one type of technology to work with another type.

              One of the beauties of some of the projects I have worked on in my 14+ years of web development is that integration was always a key part of making anything work – no company I’ve ever worked for or with has “put all their eggs in one basket” and very few I know have only one type of system. Integration is always required, PHP, Perl, Python, Ruby, ABAP, Java, .NET, take your pick at some point you have to do something with integration and for that you need to use the best tool for the job. Sometimes that tool is in direct contradiction to the strategy set out by the company and that is because of the wealth of knowledge and information that exist in some systems within the infrastructure that have been around for many years.

              So if I understand you correctly, you recommend that those systems some how be absorbed by SAP solutions, if I understand Piers correctly – that is not always possible as a SAP solution does not always exist – which in my opinion means integration and again the right tool for the job.

              However what distrubs me the most, and I think it might be just a simply misunderstanding is that there seems to be a implication in these comments that a common trait of scripters is “knocked together web applications without knowing enough about the language” it’s rather a generalization to “label” all scripting developers like this – again this is most likely simply a misunderstanding in the writing – but this “debate” has given me a wonderful idea – there will be many of the scripting community attending SDN Day in Amsterdam this year, I will be there as well and so will Kyle Shank and Matt Kent of RadRails.org – I know you are here anony so I wouldn not expect that you would join this “thought” openly however if you are going to attend I would suggest you stop by – how about a “panel discussion” during the SDN Day or SDN Clubhouse around this topic? The strengths and weakness of various languages such as scripting ones in an Entrprise environment?

              Also I honestly don’t think continuing this discussion here will bring about much as it all falls down to “personal experience” of which we are limited due to obvious reasons of “anony” users – you’ve brought up some good points that I would like to see discussed further I just don’t see commenting further to this blog as “helping” achieve anything.

              Craig

              (0) 

Leave a Reply