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.

Upgrade to WordPress 2.7

I have just upgraded to wordpress 2.7 and applied a new theme. I like the upgrade procedure, eventhough I deleted to many files and the theme. I would like my products to be just as easy to upgrade.

I like the new design, and hope to use it a little more.

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.

PYTHONPro OffRoad Triathlon 2008

This year I participated in the Offroad Triathlon. This year I have prepared a little better. I had got at new mountain bike, where it was possible to use all gears and use click pedals. I had also practiced biking and running to get use to the switching.

The result was a large improvement. Last year got a time on 1:32:05, while I this year did the 1:14:28. I had improved in all the different events. If I had got the same time last year it would have given a 2 place while I instead got a 10 place for the short triathlon. The results for this year can be seen at offroadtri.dk

The whole event also felt better, since I had a little more practice and knew what the event was about. I the running last year I had to walk a lot but this year I could run in a fast pace for the whole running trip. The biking track was also more dry this year, which also made it possible to ride faster.

I was also the lucky winner of a Aquaman wetsuit, unfortunately it was a ladies model so I cannot use it.Updated: I was able to exchange the certificate to a male model, so next year I’m going to swim much more in open water.

Next year it should be possible to perform the triathlon faster if the shape of the day is better and if I have practiced more.

Using PI scenarios

I have not been a fan of the scenarios created in XI and PI. I have mostly used the scenarios to document objects, which already had been implemented. By adopting this process the scenarios was often lacking functionality or missing important objects. The scenarios served mostly as a form of documentation, for PI developers with less knowledge of the interfaces designed.

My main reason for not using the scenarios was the following.

  • They could only be used to configure some objects in the auto configuration phase. It was not possible to generate a sender agreement, which then had to be created manually.
  • When new scenarios had to be configured, partners and systems should be selected. For configuring just a few objects.
  • The scenario cannot configure all necessary objects to be used. It is something like “Exactly Once In Order” sequence and routing rules.

With the above reasons it was I was not very excited about using scenarios in PI projects. Fortunately my colleague Emil Jessen, had a lot of ideas on why to use scenarios. The primary reason was to use them as a dialog tool to communicate integration processes with the business teams. The other reason was to use them for auto configuration of objects.

The scenarios should also make the hand over to the customers own people easier. They should be able configure the test and production environment and thereby have ownership of the solution. They did unfortunately not have the time for the configuration part, so we could not see how it worked.

The main focus was on creating a way to communicate, how we pictured each process and the messages flow in the process. The swimlane diagram is easy to understand since it deals with interaction between systems. It also described how the flow was when using BPM’s.

The use of models is going to get much more used in PI 7.1. I have tried to use the functionality as described in this blog. In PI 7.1 the models can get more complex and be used to describe how the business works. I’m looking forward to see if the models in PI 7.1 can give a better understanding of what is going on or they are too complex for the application consultants.

To streamline our use of scenarios the following guidelines was created.

  • The scenario should describe a process and the scenarios should be named after the process.
  • Scenarios was created in the beginning of the realization phase and populated with dummy actions until it had been defined each action.
  • Actions should be marked as with start and end action(s).
  • Actions used in a scenario should contain a description. This description should contain information on what the action is doing. It could be send message, provide lookup service, consume lookup service and send message. And then a more detailed description on what the interface did.
  • In descriptions for actions and scenarios the technical specification number was added, it was therefore a lot easier to find a scenario by using the search functionality.
  • Actions can have multiply interfaces, which could be used in different scenarios and in different ways. As long as the different message does the same it could be an IDOC and an BAPI, which both creates an invoice.
  • Communication channels temples should be places on all communication channels, which needed a sender agreement.
  • All configurations of scenarios should be done by using the scenarios, except where the limitations are as described below. This mean that it is easy to reconfigure all interfaces in a PI system, simply delete all configuration objects, except communication channels and then auto configure everything.

A scenario could look like the following. Emil had also taken the time to translate the actions to English.

It is easy to get the auto configuration for work for sender agreement, but was not documented where I looked. The solution is simple. Just place a Communication Channel Template on the sender side in the Connection between actions like showed below. It is then possible to select a communication channel in the configuration. Venkat Donela had a blog where he describes how to use the communication channel temple, I was just pointed to this blog recently.

We still need a way on how do document, which changes there need to be implemented after the configuration has been performed. This could be creating Routing determinations and the sequence for interface with EOIO. We have currently documented them in our cut-over plan, so we know what to do when we go live. Have anybody solved this problem.

I got a comment about the diagrams from one of the application consultants. He thought the diagrams were a nice way to represent what did happen in the interface. For them it looked like the solution maps, which they where use to see. It was nice to know that the diagrams could be used by the business experts to show what we were doing and we are on the right track in with the development.

Scrum and SAP projects

I have this week certified as a Scrum master, after a two day course. And I will therefore like to share, some thoughts on, how I think Scrum can be implemented in SAP projects. I have no experience in project management except for at team level and being a participant in SAP projects.

Scrum is a framework designed for Agile projects. The article “Scrum in 5 minutes”, gives a pretty good understanding of the concepts. The basic idea is to make prototypes, add business value continues during the project and remove impediments.

The opposite of scrum is the waterfall method with separate phases for each task like specification, analysis, design, implementation, test and deployment. The waterfall model has some challenges.

  • The business or customers does not have a complete idea of what they need before the see how a model works. This result in change requests along the way, which is more expensive the later in the process they are found.
  • Features is requested that is never used a study published in xp2002 showed that 45% of features in software is never used.
  • It become more difficult to change or correct something, in the later stages of the project
  • During the test face everything has to work and then fixed and retested.
  • Hand over between the different faces requires a lot of documentation, which can be difficult for other persons to understand or requires a lot of time on creating.
  • The method assumes that we do not live in a complex environment, where changes does not occur.
  • Often has overrun in time, price or bad quality.

I would say that ASAP is a clear waterfall method, with a analysis, implantation, test and go live face. ASAP contains some accelerators and templates to assists in the implantation. ASAP therefore contains most of the challenges stated above.

Scrum acknowledge that it is not possible to plan everything into the future and is therefore using 2-4 weeks iterations, which each have to result in a “workable” product. A large part of the framework is dealing with how to prioritize the most imports features from a business value perspective. The target is to create hyper productive teams, which produce more business value per resource.

 

 

A study done in Systematic , a CMMI5 company (so they must know what they are doing), showed that it was possible to halve the project cost and provide better quality than a waterfall implementation with Scrum.

Scrum can probably not save the world of projects. Like all other frameworks Scrum has some challenges, which can cause problems with the implementation.

  • First of all organizations have to acknowledge they cannot plan feature the want in advance.
  • Many organizations leave parts of the framework out; this will not result in a ScrumBUT with a lower productivity.
  • The organization has to believe in the scrum approach and leave the groups alone in the sprints. If not it can result in lower production and a product which does not provide the correct business value.
  • Other revenue models have to be created for consultancies, to adopt Scrum instead of a high paying waterfall approach.

 

I’m currently trying to figure out which parts of Scrum, we can use as an Integration Team in an implementation project. It will result in a ScrumBUT, but it will hopefully provide some experiences on how projects can be managed, from a micro level.

 

Do you have any experience in running Scrum in SAP implantations, and would like to share some experiences about it?

Use proxy to inspect http/soap requests

I have developed some PI webservice scenarios, that I needed to test. When I test webservice I use .NET WebService Studio, which I’m unable to find anymore. It is a small free application that can use a WSDL to create and interface to test the application.

When I tested this interface, I got the following error: System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly. It took a while to trace what the error was, because the processing looked fine at the PI system.

To trace the problem I deceived to place a proxy in between the .NET application and the PI SOAP adapter. I had earlier used Webscrab as a proxy to see how the used HTTP request looked and change some parameters. The new version of Webscrab is a Java Webstart application so it is much easier to get started with.

When the application is started, the user is requested to select a database to store the requests in. I normally use blank password, since the requests is just private.

The application looks like the following.

It is possible to change the port, for where the proxy listens in the menu Plugin->Proxy->Proxy Listeners. Default is 8008.

In the .NET application the proxy have to be changed to http://localhost:8008 and it should then be possible to see the incoming requests in the log.

When I placed this proxy between the two applications, I got the response that I expected and the .NET application also received the correct data.

If you need to change some requests, it is also possible. From the Plugin -> Intercept Requests and POST.

Then for each new request you should get a popup, where it is possible to change the HTTP request before it is sent to the server.

Modeling tools in PI 7.1

With PI 7.1 it is possible to create Aris Models within the Enterprise Service Builder. This will make it easier for the integration team to model the process and interfaces.It is possible to go from the high level business process models, all the way down to an interface implementation and configuration of integration scenarios. The use of models adds an extra layer of documentation of the business processes in conjunction with the Enterprise Services (ES). The models can be used to get an overview of how a scenario is created.

This paper will contain information about which models can be used in PI 7.1 and which meaning they will have for a PI developer.

The Sales Order model is based on the ES for sales orders. But the modeled system contains more information than it is possible to find on ES workplace. What is added to the models in the ESR is how the services can be connected in a specific scenario.

At first look at the models there are a lot of different models. It takes a little while to get used to the models, and figure out which models can be used for which purpose. There are 12 different model types, and all of them can be used for describing a business process in different ways and levels.

At the highest level different integration scenarios are grouped together. An example of this is the SAP Scenario Catalog, which is a grouping of different scenarios. This model makes it easier to understand how different scenarios belong together and to find the scenarios that have something in common.

An example of the scenario catalog is the following.

An Integration Scenario is a high level overview of what Deployment Units are used. In each Deployment Unit there is one or more Process Components which can contain a number of process steps. The connection between the Deployment Units can be linked to information about the integration scenarios.

The interaction between the Process Components can be described in a ProComp Interaction Model.

A ProComp Interaction model shows how different Process Components relate to each other, for instance the message flow between Process Components. An example of this is showed below.

The ProComp Interaction model can contain information about what Service Interfaces are used and the mappings they contain. This information can be used to configure an Integration Scenario by adding information about business systems and where the different process components are installed – and by selecting adapters. Then it works just the same way as an Integration Scenario in PI 7.0.

The ProComp model can also be used to describe how the flow is within a Process Component. This type of model seems to be more useful if the aim is to document how Enterprise Services are connected within a Process Component. An example of what the ProComp model could be used for: To describe what is going on in a BPM (Integration Process in PI) which can then later be created based on the model.

It is still possible to make use of integration scenarios from XI 3.0/PI 7.0. These scenarios do not explain the business in the same detail as some of the other model types. They do, however, provide information about which connections are used and how the messages are mapped. The integration scenarios are easier to understand for a PI developer since they give information about which connections are used in a direct fashion and because they have been used earlier versions of XI/PI.

It takes a little while to get used to working with the models in PI 7.1 and to create models which can be used and understood by developers and Business Process eXperts ( on SDN SAP has a BPX community).

The use of models does seem to create some extra overhead compared to a top-down approach which starts with an Integration Scenario and the objects are created to fit into the process. To be able to make such a scenario one would normally create a drawing to describe what is going on and to support development of the scenarios. This drawing is often a process diagram, for instance in Visio, PowerPoint or on paper. With help of the built-in model tools it is now possible to store such models within the ES Builder, thus serving the purpose of documenting the process and context to which the interface belongs.

I recommend to invest time in establishing naming conventions for modeling and guidelines for when and how modeling should be used.

A question which has to be answered is if models should be created for all integration scenarios – or only when Enterprise Services are involved? I probably need to use modeling in real projects and then evaluate if the use of modeling makes sense.