...by Daniel Szego
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego

Sunday, November 22, 2015

Notes on the Logic of IT Project Management

As in a normal communication there are two answers for a question :"yes", or  "no". In IT Project management there are usually three ones: "yes", "no" or "let we create an excel table". And surprisingly, the answer in most cases : "let we create an excel table".  

Sunday, November 1, 2015

Integrating MatchPoint with SAP (a step by step initial approach)

Integrating MatchPoint with SAP is pretty easy as a first approach. You have to do two things: 
- get an SAP connector to read out some information from SAP
- implement a data provider in MatchPoint with the SAP adapter to use the imported data.

So let we have the steps in details:
STEP 1. Let we assume that we want to see the controlling area names from SAP controlling:

Figure 1. List of controlling areas in SAP.

STEP 2. Let we create some integration with SAP, there are many ways of doing that ranging from BAPI calls to web service integration through Netweaver. I m choosing the most simple SAP .NET connector
STEP 3. Let we create a Visual Studio project console application and reference the SAP.NET connecor dlls: sapnco.dll and sapnco_utils.dll. I am probably using a little bit old version, because for me it was working only with .NET framework 4.0 and not with 4.5 or higher. 
STEP 4. Let we create a basic connection class named SAPSystemConnectMP to store the SAP connection information, like port, system number, access information...:

    public class SAPSystemConnectMP : IDestinationConfiguration
        bool IDestinationConfiguration.ChangeEventsSupported()
            return true;
        public event RfcDestinationManager.ConfigurationChangeHandler ConfigurationChanged;
        RfcConfigParameters IDestinationConfiguration.GetParameters(string destinationName)
            if ("K47".Equals(destinationName))
                RfcConfigParameters parms = new RfcConfigParameters();
                parms.Add(RfcConfigParameters.AppServerHost, "");
                parms.Add(RfcConfigParameters.SystemNumber, "00");
                parms.Add(RfcConfigParameters.User, "root");
                parms.Add(RfcConfigParameters.Password, "***");
                parms.Add(RfcConfigParameters.Client, "800");
                parms.Add(RfcConfigParameters.Language, "DE");
                parms.Add(RfcConfigParameters.PoolSize, "50");
                parms.Add(RfcConfigParameters.MaxPoolSize, "100");
                parms.Add(RfcConfigParameters.IdleTimeout, "6000");

                return parms;
            return null;

STEP 5. Let we create a wrapper class for the ControllingArea, with the static setup procedure that calls the BAPI_CONTROLLINGAREA_GETLIST Bapi and from the result takes the CONTROLLINGAREA_LIST table and lists all controlling area name and code.

   public class ControllingArea
        public string ControllingAreaCode;
        public string ControllingAreaName;

        public static List<ControllingArea> getAllControllingAreas(RfcDestination destination)
            List<ControllingArea> ret = new List<ControllingArea>();

            RfcRepository repo = destination.Repository;
            IRfcFunction controllingAreaList = repo.CreateFunction("BAPI_CONTROLLINGAREA_GETLIST");

            IRfcTable controllingAreas = controllingAreaList.GetTable("CONTROLLINGAREA_LIST");

            for (int cuIndex = 0; cuIndex < controllingAreas.RowCount; cuIndex++)
                controllingAreas.CurrentIndex = cuIndex;
                ControllingArea area = new ControllingArea();
                area.ControllingAreaCode = controllingAreas.GetString("CO_AREA");
                area.ControllingAreaName = controllingAreas.GetString("Name");
            return ret;

STEP 6. Let we implement a MatchPoint Data Provider, of course after referencing the MathcPoint dlls, possibly from the development kit : Colygon.MatchPoint, Colygon.MatchPoint.Server and Colygon.MatchPoint.Snow.

    public class SAPDataProvider : BaseDataProvider
        public string[] List;

        public override BaseDataProviderInstance CreateInstance(string cacheKey, IEnumerable<string> columnNames)
            return new SAPDataProviderInstance(cacheKey, this, columnNames);

STEP 7. Last but not least let we implement a data provider instance. Perhaps the most important part of the instance is the GetInternalData function. It opens an SAP connection through the configured connection class, queries all the controlling areas and transforms the names to a simple string list.

   public class SAPDataProviderInstance : BaseDataProviderInstance
 private readonly SAPDataProvider provider;

 public SAPDataProviderInstance(string cacheKey, SAPDataProvider provider, IEnumerable<string> columnNames) : base(cacheKey, columnNames)
  this.provider = provider;

 protected override CachePolicy CachePolicy
  get { return new CachePolicy(CacheGranularity.NoCache, 0); }

 protected override IEnumerable<object> GetInternalData()
            SAPSystemConnectMP sapCfg = new SAPSystemConnectMP();
            catch(Exception ex){}
            RfcDestination rfcDest = RfcDestinationManager.GetDestination("K47");
            List<ControllingArea> cAreas = ControllingArea.getAllControllingAreas(rfcDest);
            List<string> res = new List<string>();
            foreach (ControllingArea area in cAreas)

            provider.List = res.ToArray<string>();
            return provider.List;

 public override string GetCacheToken()
  return null;

STEP 8. Having compiled,we have to registrate everything in GAC (the SAP connector DLLs as well) and we have to registrate the DataProvider in the matchpoint configuration as an external assembly and of course IISreset at the end.

Figure 2. MatchPoint Configuration.

STEP 9. If everything went well, you have to see the new dataprovider in your system. So as an test we can create a composite WebPart setting the SAPDataProvier and showing with a pattern transformer the DataItem.

Figure 3. Composite WebPart configuration.

STEP 10. If everything wen well, you should see the list of Controlling Areas directly from SAP.

Figure 4. Controlling area information in MatchPoint from SAP.

The ways of customizing a software

Previously I always had the opinion that there are basically two ways of software development:
 - having a project based development, starting by a business analyst to gather the requirements, setting up the architecture, making an implementation and delivering to the customer, or
 - creating and selling a ready to go product, starting by a product manager, having some implementation phase and then selling at the end. 
However the world as usual is more complicated. 

I am making analysis based on how much a product is possible to be customized from an end user perspective, having an analogy through the different restaurants and fast food restaurants. In this sense I would at least distinguish the following four types of software products:
1. Ready to go products
Ready to go software products are like sandwiches in a supermarket. You can buy them as they are, you can usually choose between different sandwiches, however you do not have the chance change the product itself, like having your sandwich with mustard and mayonnaise, instead of ketchup.  

Figure 1. Ready to go product.

Typical "ready to go" software products are the different mobile and or SharePoint Apps. They provide some very specific but limited functionality, they usually specialize on the B2C customer segment and both the buying and the installing mechanism are as automatic as possible, as an example via online stores.

2. Complex Products.
Complex software products offer more space for customization, despite they are products for a very specific need. They are like ordering a menu at Mc Donald's, you already have some possibility to customize your menu, varying several parameters, like french fries or salate and of course you can choose if you want to have mayonnaise, ketchup or both.

Figure 2. Complex Products.

Such complex products are usually the domain specific business applications, like quality management system, special applications for transportation, financials, logistic and so on. The avrage complexity of these software systems are usually bigger than to be only self-service, as a consequence buying these products requires a certain level of consulting. As a consequence they usually sold in a classical way instead of online shops, and with a certain level of consulting services as well.

3. Frameworks.
Frameworks are actually not products, however they are certain way of conveyance chains that are capable of many different, slightly different products. The best example is subway, there is actually a pretty complex customizing process that help to deliver a couple of thousands of slightly different sandwiches in a pretty efficient way.

Figure 3. Frameworks

Such software frameworks are for example, the different BPM and workflow solutions, like K2 or Nintex in the business field, they do not provide ready to go solutions, instead possibilities to build up many different customized processes. Actually SharePoint itself can be regarded as well as a general framework for delivering social collaboration solutions. Buying and installing these solutions usually splitted into two parts: buying the framework itself and buying the consulting service for that.

4. Custom project development
Project development is the very classical way of software development, with business analyst, requirement engineering and then implementation and delivery. It is like a five star restaurant, where you have a small discussion with the waiter discussing your taste, the possibilities and then getting you burger exactly as you want.

.Figure 4. Custom project development.