Simple as possible but no simpler

The design goal for SharePoint is “make it as simple as possible to create a web site”. A web site for a project or a team that type of a web site that is. And SharePoint works well for that purpose, most project leaders can with very little training create a project site, where all documents, conversations, plans schedules etc. can be shared within the project team. The same goes for a team site. A team site just have more longevity. A simple isolated web site well integrated with MS office and outlook that is what you easily can create with SharePoint. And that is great, it is what most teams and project needs, common documents, calendar etc. Using defaults and out-of-the-box solutions, you can create a simple web-site for collaboration in no time. The problem with SharePoint starts when the team/project leader begins to enhance the site with more advanced functionality SharePoint was not designed for. E.g. SharePoint store data in lists, it is easy and works well to extract values from other list via lookup fields, any other interaction between lists works less well. If you use values from another table for a pull down menu, you may see timing problems, since a value in a list is not visible before some cyclic background process is executed, in a real database the values are visible to all the split second you commit you update transaction, in SharePoint you have to wait. When I talk to SharePoint specialists they tell me this can be fixed. When I ask why it is not fixed from the beginning I get the answer “it’s more complicated”.
- “Well can you fix it for me?”
- “No I can’t I’m not a developer.”
This is something I heard more than once, it seems SharePoint specialist are specialists in tweaking SharePoint but no programmers. Nothing wrong with that, the problem is you need programming skills to anything more than SharePoint is designed for. And then you need to consult a consultant with SharePoint programming skills. And now SharePoint is not so simple anymore. E.g. When you access a list’s fields in programs you use the internal name, this is the hidden name a field gets when it is created, when “the sharePoint developer” rename a field, he/she is just changing the “display alias” not the field name, but you do not see this, you think you rename the field and there is no simple way to retrieve a list of a list’s internal name, this makes it unnecessary awkward to develop SP programs. When SP was designed the internal name must have been regarded as ‘too complex, hide it’. However in the CSOM SharePoint framework it is not hidden, there you have to use the internal name. Internal name is not the only design flaw. This list is long, I’m just to inexperienced to naming them all, but ISO is another. US is not only the United States of America, it is America and the World, who has ever ever heard about ISO? If you want a default compliance with e.g. date ISO 1806 format, you have to change US default locale to some obscure nationality like ‘swedish’, not really what you want. It can sure be fixed, but probably complicated (see above). US standards, a nation who still use Henry the VIII thumb to measure distance. Don’t get me wrong I like US, especially New England if I could I would settle down in Massachusetts or New Hampshire, but US and international standards do not go well together, so the creator of a SharePoint site I know chose locale ‘swedish’ and built an ‘advanced’ app i.e. using sophisticated features like  indexes, unique constraints, custom input validations. All that worked until an unfortunate script upgraded the template also by accident reverted the locale back to US. Not much worked afterwards, take field formulas as an example, they depends on the locale, change locale is a fast way to remove all input validations. Basically you kiss your ‘advanced’ application goodbye by changing the locale.
Changing a SharePoint site’s locale should not be allowed and it should be simple to print a list of field internal names, yes I know you can do the latter. Display the ‘all items’ view make the browser display the page source look for all ‘realFieldName’. But why do you want to see the real field name it s just a distraction only for the techie who likes to complicate simple tasks like creating a web site.



Recently I got a comment to the post PHP 5.6 SAPRFC & SAPNWRFC asking about PHP 7 and SAPRFC.dll. I had in mind to have a go at PHP 7 and SAPRFC Linux this summer. But my job got in the way. All of a sudden I became a SharePoint C# backend developer and the unhappy owner of a SharePoint app, this plus my ordinary job as a IT architect plus giving a BI team a hand now and then had been too much for me. You need focus time learning something as complicated as a software platform, a computer language and frameworks. Being interrupted many times every day with other matters like ‘It seems I am not authorized to update this product classification code, can you fix it now? We need this code for the book closing tomorrow’ made it impossible for me to have a look at SAPRFC and PHP 7 and (UTF-8). My plan B, convert my code using SAPNWRFC by Piers Harding, looks like a better solution. Today I use SAPNWRFC when I need UTF-8 capabilities, using just one SAP connector is a better solution but the conversion will also take time I do not have at the moment. I have not had a summer vacation yet, it looks like I can have a short one in October, for those of you who doesn’t know, October in Sweden is not a good place for outdoor summer activities. October here is nice but you need more cloths than swimming pants and you just don’t go swimming, not even in September. It looks like My PHP code will stay on PHP 5.6 until next year. And it's more likely I abandon SAPRFC in favor of SAPNWRFC, than I try to upgrade SAPRFC to support PHP 7.

It would be good if someone at SAP could give an advice how we should connect from PHP. I hope SAP supports those heroes who creates and maintains connectors to popular languages like PHP.