When I first learned about SAP, I was led to believe it was insular. Sharing its data or uploading data to it was possible, but expensive and discouraged. If you have SAP, stick with it.
Then came XI, the SAP eXchange Infrastructure which is the SAP offering for Enterprise Application Integration (EAI), or now rather Enterprise Service Bus (ESB). With it, you can build marvellous Service Oriented Architectures (SOA).
So what?
Well, my experience of XI is that its used as a replacement for IDOCs, BAPI, EDI and the like. Instead of those hard to use protocols, simply subscribe to a published web service.
But hang on… If SOA is in use, couldn’t we go a step further? SAP isn’t very good at really rich clients (GUIs), and chances are, to develop one would cost a huge amount.
So what about the idea of building your business logic on top of existing SAP functionality, so that you extend it to suit your business processes, and then build that rich client on top of the SOA that SAP can offer from your business logic?
An example would be the project I’m working on at the moment. We need to build a planning tool for use in Service Stations for trains. Service stations consist of a large number of platforms where trains can be serviced. Some types of service can only be done on some platforms (axle change for example). As well as planning which trains go where and when and for how long, teams need to be allocated to each service, and only some teams can perform some types of service.
Now service management (that is what work needs to be carried out on what trains) is already in SAP. It provides a report for each incoming train, and the teams can update the reports with new found problems and the work that they completed.
Personnel management (who works in which team, and which team works on what platforms, etc) is not currently in SAP at this client, but I am sure with its HR functionality, it wouldn’t be hard to get that working.
The physical planning of locations and time slots could be hard to implement in SAP if it doesn’t already exist, but that could be where you develop your business logic.
Finally we need the GUI. Think along the lines of Microsoft Project, and Gantt charts showing task planning as well as resource allocation. Optimisation of resources as well as track space is one goal here.
That type of GUI with drag and drop functionality, slick GUIs, realtime updating of the plans, etc. is apparently not really possible with SAP, and if it is, is very expensive because you need to find someone who can do it.
But with Java technologies like Swing or Eclipse Rich Client Platform (RCP), building a GUI like that is easy and fairly cheap (Java developer rates are currently around 30% less than SAP developers). So instead of building the back end in Java EE and calling an application server, just call SAP XI instead…
Although its technically very feasible, suggesting this type of integration still brings strange looks. While XI is still relatively new, people have not got used to thinking about integrating like this. Integrating two stand alone systems is fine. Using XI to provide an ESB or to connect to one is fine. But Building a single system out of an SAP backend and a Web Service capable front end is somewhere the people I work with don’t want to go.
If you have other experiences, please mail me at sap_soa_gui@maxant.co.uk.
