The future of integration consulting

For the last couple of years the job considering integrating legacy systems with the SAP ERP system has stayed the same. Each system is unique, so integration had to start from scratch. There could be some limited reuse between integrations, but they did not have a large impact.

Many of companies are going to use SaaS (at least that is what many company is betting on). SaaS strategies could be seen as a way to get a best-of-breed application. Some of the SaaS applications are probably going to replace old legacy applications or reduce the number of more legacy applications being created. Integration between SAP and SaaS applications are wherefore going to play a large role in the integration work done with PI.

My experience with integration with a systems, is that it takes an average of 10 days pr system (The development could be completed within 2 days, but support during testing and bug tracking is required). If the complexity is getting larger or requires the use on new services in SAP, the number of days will skyrocket. Large parts of the integration work are concern error handling, when some unexpected data is received. The price for 10 day integration is at least €10.000, but with a high uncertainty. Such start prices will many business cases fail in adopting a SaaS application, because of the initial investment.

One way to lower this price is if the SaaS vendors also use the same Enterprise Services that SAP is exposing. Then integration will just be to connect the two interfaces and will just require testing for the business functionality. From a customer perspective this would be the ideal situation, and lower the cost of integration.

If there are no Enterprise Services to cover the SaaS integration, two things should happen; Either an Enterprise Service is created or a PI integration is created. The two options can be produced by a consulting partner and then shared under some license. Open source could be an option if it was supported by the SaaS provider.

Creating reusable integration parts can be difficult, especially in small markets like Denmark. The Danish government was very keen on electronic invoices(OIOXML), using the UBL standard. That led to a race for consultancies to create templates for integrations. I do not know any company, how got a large enough part of the integrations, to have justified a large upfront investment a shrink wrapped solution.

Reuse is possible for some domains. I have been involved in project, where reuse of BPM functions lead to easy integration with the 2th and 3rd application. In this project the Enterprise Service was implemented as a ccBPM in PI. The later integrations needed some adjustments to support the new functions and integration protocols, but the overall framework proved successful.

We asked the vendors of the third party application, if they had any integration to SAP. They all did have some integrations, but for different versions of SAP and application components. Challenges like this are going to continue because of the flexibility in SAP. In some cases can different modules handle the same functions. I doubt an Enterprise Service should handle the functionality in two different modules.

With SaaS application is the marked larger since it is global and allow for packaged solutions. The packaged solutions can both be PI mappings and BPM’s or Enterprise Services and sold via Ecohub or from the SaaS vendor.

A way a business model for this could be to give a lower rate on the first implementation; then sell this integration to other customers. It will take a few iterations before a shrink wrapped integration can be released.

To have an integration for SAP must be a really interesting for SaaS providers, because it will make it easier for customers to start using their services. If the customer is going to spend a large number of days on integrating the application, it is less likely to happen. Without an integration to the ERP system, some of the benefits are removed from the application.

For consultants will it also be interesting, if you only have to produce something once and then be able to sell it multiply times. The issue is then how the global marked can be supported, but remote consulting via VPN can probably solve most of the issues.

I’m looking forward to see if, this is going to be the business model for future PI consultants.

Release of PI documenter tools as open source

I released the two services for PI to get documentation of mappings and to compare two mappings to see what have changed. The release to those services can be found in the two
blogs.

After the release people have been asked if it was possible to run the tools at the users own computer instead of the server version. And I have been thinking about releasing the scripts as commercial products to accommodate this request. It is possible to create compiled PHP code, which can be executed at local PC’s. I did decide against it because it would require a product to be more mature then the product is and did not believe the marked was large enough and marketing would be difficult. By releasing the product as open source it might be possible to get other to contribute and create a service, which could help many more.

The product was original designed to run on a server in a controlled environment. But with this version I had to refactor some of the code to support the usage a client perspective. A problem is that script is extracting a lot of files from the XIM files. These files need to be cleaned up and I used the quick solution to use the windows Delete command to do this clean up. There are some other places which have not been cleaned up yet, they will be cleaned up in the next release.

One of the challenges with releasing software as open source is that it exposes ones coding capabilities. I would say that there is a long way to go before I’m able to get a living from coding PHP. The code seems to work, but the refactoring is a little more time consuming.

You can find the code and installation guides at code.google.com.

If you want to help with improving the code, please join the group and help improve the product.

Thoughts on versioning of PI components

This blog describes some of the thoughts that I have on using versions for different software component versions for development and support tracks.

Why

The use of versions as a way for managing releases has been used for a long time to maintain programs. With the help of a revision control program is it possible to get an overview of what releases are build and which changes have been made. This will make it easier to give a better understanding of what is promoted to production.

On my current PI project we have different phases. We have just gone live with the first part and is currently developing the second part. After each phase a release is tested and moved to production. While the second phase is being developed the first phase must be supported, to ensure corrections can be moved into production before the next release.

PI makes it possible to use different versions of software components, to make it possible to use each version. Like other versioning tools is it a challenge to use it correct. I’ll describe, how we have used it and what we have learned.

How to use versions

The main part of configuring different versions is fairly easy. It just requires the users to create a new software component with a new version identifier. The first release will have version 1.0 and the second version will have version 2.0 and otherwise will be placed in the same products. Remember to add dependencies to the version 2.0 of the interface components, assuming the interface components also are upgrade. The version 2.0 should also be installed on the same systems as the version 1.0 components, otherwise it could cause problems.

Create the namespaces which will be used in version 2.0. Then make a release transfer, where the objects from version 1.0 are copied to version 2.0. The Release Transfer can be found at Tools Menu, and it works much like the export function. Only content from version 1.0 is copied if a similarly namespace is in the version 2.0 component. You have now copied the content to the version 2.0 and can make changes in each component separate.

With the copy all object is copied to version 2.0. Objects will continue use the depended objects from version 1.0. For instance will a Message Mapping still use the Messages from the version 1.0. Unless the Message has been imported via dependent object, then the Mapping will use the Message from version 2.0 of the dependent software component.

With this upgrade maneuver the objects, will still be the same with very little change to them. It is a problem in the beginning but after getting use to it seems like a good idea. When changes are required simply alter the scenario to use a new interface mapping and maybe actions, and then add the functionality and the functionality can be used.

We tried to copy objects which had imported messages from the imported components. We therefore had the message types from version 2.0 in our 2.0 mappings. I do not think that this was a smart move, since I more like the idea of having to select when to upgrade a message type. Therefore this trick only works for abstract mappings, which have to be imported via the imported components. .

Objects and scenarios

I have earlier written about using scenarios for documentation and dialog tool for communicate the process with the business. With the help of scenarios, it is easier to maintain which version will be used.

When scenarios are copied to version 2.0 it will still point to version 1.0 mappings and actions. When changes are made to the version 2.0 object the scenario must be change to reflect that the mapping is changed. It is thereby possible to make configuration on a system, while maintain everything from version 1.0 except the mapping which has to be changed.

Support

The use of two versions can cause problems. When a support issue arrives, it must be correct at version 1.0. But this change is not maintained in version 2.0. It is therefore necessary to somehow maintain both versions. If this is not done the problem will exist again in when version 2.0 is deployed. This can be difficult because it requires the users to implement the changes in version 2.0, and it gets more complicated if the involved object has been altered for version 2.0. If objects have not been altered in version 2.0, release transfer is possible again. If the object has been changed in version 2.0, the release transfer will show that conflicts exist.

To avoid having to develop thing twice and make sure that, we make the same changes to version 2.0, we made some changes to the process.

  • First we have decided that some processes will not be changed in face 2. Those object have been change so we use the version 2.0 in production. This will remove the need to maintain those objects in both versions.
  • Secondly we have decided on some systems which will be sent into production and maintain in version 1.0. This system shared BPMs with other systems, which will be changed in version 2.0 to support new features.

Namespaces and versioning    

The use of namespaces could make scenes for some areas. Then the version number could be a part of the namespace. It would make it clear if an object contained content from a different version. If this approach was use then it will not be possible to use release transfer, because the namespace differed. I think that this probably makes most sense to use when communicating with third parties and the WSDLs need to be shared and agreed on which versions are used.

 

Testing

Since we need to be able to support the current running production system and creating we have to have to lines of ERP systems. I believe that this is a common setup for ERP projects. For the PI development it is just to configure the correct scenarios version for the correct ERP and third party systems. It hereby seems possible to perform the support alongside development of phase 2.

Conclusion

The use of versions is pain and requires developers to check what they are doing. I have avoided the use of versions for 4 years now, but have finally agreed to use version. The main argument was, that project had deliverables in two stages. I believe that it is correct to use versions, but it still requires caution since it is easy to break the setup.

Easy access to SAP sites

I have been using Launchy to get easy access to search on SAP notes and start my SAP GUI. Launchy is an application which can be used to launch other applications or access websites. Nigel James wrote about how to use Launchy in a blog post and how to access sap notes easy.

Recently I discovered that Firefox was also working on a similarly project called Ubiquity. The difference is that Ubiquity is placed within the browser and can access the same information as the browser. It has easy access to google maps for an address which has been selected and complete other tasks that you would do in your browser.

It is possible to create some commands you self, which can be used to enhance your browser experience. For instance it could be to change tabs or to make the tasks that you normally do on your favorite sites. The commands are written in Javascript, and there is a pretty good tutorial on how to get started.

To get started using Ubiquity just install the Firefox plugin from the Mozilla site.

After you have installed the plugin goto the command press CONTROL and SPACE and you will get a popup in our browser like the following. In this window you can enter commands to Ubiquity.

Try commands like map (address) or in an edit field mark an url and use the command tinyurl.

I have written some commands which can be implemented pretty easy. To implement them use the command command-editor.

In the command window insert the following code, and it should be possible to run the commands.

/**

* Ubiquity Command java scripts

* Used for searching SAP sites

*/

CmdUtils.CreateCommand({

name: “sapnote”,

description: “Finds SAP NOTES”,

takes: {“note number”: noun_arb_text},

preview: function( pblock, noteno ) {

pblock.innerHTML = “Open service markedplace for note: ” + noteno.text ;

},

execute: function( noteno ) {

var url = “http://service.sap.com/sap/support/notes/{QUERY}”

var urlString = url.replace(“{QUERY}”, noteno.text);

Utils.openUrlInBrowser(urlString);

}

})

CmdUtils.CreateCommand({

name: “sapql”,

description: “Open SAP Service Markedplace”,

takes: {“site”: noun_arb_text},

preview: function( pblock, siteType ) {

pblock.innerHTML = “Open SAP Service for : ” + siteType.text ;

},

execute: function( siteType ) {

var url = “http://service.sap.com/{QUERY}”

var urlString = url.replace(“{QUERY}”, siteType.text);

Utils.openUrlInBrowser(urlString);

}

})

CmdUtils.CreateCommand({

name: “sdn-search”,

description: “Search SDN”,

takes: {“query”: noun_arb_text},

preview: function( pblock, query) {

pblock.innerHTML = “Search SDN for : ” + query.text ;

},

execute: function( query) {

var url = “https://www.sdn.sap.com/irj/sdn/advancedsearch?query={QUERY}&cat=sdn_all”

var urlString = url.replace(“{QUERY}”, query.text);

Utils.openUrlInBrowser(urlString);

}

})

The script contains three commands.

  • sapnote which take a service marked place note number and display a page with the note.
  • sapql is to access SAP Quicklinks like SWDC or notes
  • sdn-search which make a search on SDN for the query you have made.

The sdn-search search command look like the following.