Duet Enterprise is real, effort is in it’s correct application

In the 1st week of May, The Next View participated in the second edition of the Duet Enterprise Velocity event. We already joined the first edition, and thus are familiar with the Velocity concept. As consequence, we could start immediate at the begin of the Velocity week on the realization of our customer’s scenario: Coöperative Learning.

Duet Enterprise is a given; real effort is in it's application AND understanding the business process + SAP business package

Noteworthy finding is that Duet Enterprise knowledge + experience is a necessity to successfully and productively apply this SAP-SharePoint interoperability middleware. However, this alone is not sufficient. Also required is that your customer has, or can reach, a clear vision of the application context they aim to achieve. In a normal project (with aim to deliver business value) this is of course the essential starting point. In our development approach we facilitate this by usage of mock-ups: discuss and derive in workshop(s) together with customer representatives the application functionality and behavior. The visualization format can be as simple and basic as sketches on paper, onto fully operational prototypes the customer can click through. SharePoint GUI + SharePoint Designer are very helpful for achieving the latter.

With the customer vision visualized in mock-up, the next step is to map this User Interface Design (UID) onto the combined SAP and Microsoft landscape. Here it is essential that you understand, and be aware of the behavior of the SAP business package building blocks.

An example to illustrate this

Part of Coöperative Learning scenario is to deliver Training Collaboration Workspace. Each workspace displays information about the training itself, about the participants, qualifications. SAP Enterprise Learning contains standard BAPI Function Modules to retrieve this information. It appears as simple as to identify the proper Function Module, and expose this via Duet Enterprise to SharePoint. But in reality the required insight in the SAP business package goes further. You must also be aware of the proper way of Function Module invocation, depending on the application context. For our Training Workspace, we apply the standard BAPI LSO_TRAINING_GET_DETAIL_C to retrieve training title, description and date. On day X this worked correct. Next morning, I received functional error ‘Course already passed’ from SAP LSO. It appeared as if the standard BAPI FM was not usable to retrieve data on elapsed training data, making it unusable for historical workspace context. Strange enough, a co-worker could still retrieve the training data. Our differences? He was enlisted as participant in this training, in contrary to me. And the standard Function Module responds on this current user context by only allow course participants to view the training data. That is, if you invoke the Function Module in it’s default modus ‘User_Role = Learner’.

When you overrule this for anonymous modus, you can successfully retrieve the training data also for elapsed dates, irrespective of the participation status of current user. A (proper) Duet Enterprise manner to do this is in the Gateway Model mapping.

Blueprint Duet Enterprise scenario's

The Next View recognizes the derivation and mapping from business vision via UID to the combination of SharePoint capabilities and SAP business package functionality + building blocks as essential step to deliver the correct application. We therefore incorporate this structural in our applied Duet Enterprise development process. As soon as we receive the initial business approvement on the UID translation of the business vision, next step in The Next View process is to deliver a Blueprint for the Duet Enterprise scenario’s that can be identified from the UID. Involved roles in delivering the Duet Enterprise Blueprint are a) Duet Enterprise Solution Architect as owner and facilator, b) SAP Business Analist with functional and high-level technical knowledge of the SAP Business Package, and c) SharePoint (Lead) Developer with knowledge of the SharePoint front-end capabilities. The purpose of the Duet Enterprise Blueprint is to derive and describe the high-level Solution Design; identifying the SAP and the SharePoint side. In the Solution Design, also fundamental design decisions on the SAP-SharePoint boundary are made and argumented. And when applicable, for alternative approaches explained why decided not to apply that.

In the process of derivng the Blueprint, it may also become clear that the requested UID cannot, or only with substantial development effort (= costs), by achieved by the SAP + SharePoint combination. Whenever such a consequence is identified, this is discussed with the UID expert and business. Is it feasible to alter the UID to accompany the standard SAP + SharePoint functionality? And if not from either functional or UID perspective, is the business willing to pay the extra development and also maintenance costs? Thus, the Blueprint derivation has an iterative effect and relation towards the UID and the application functionality.

Using ServiceLocator in Sandbox requires pre-generated xml-serialization

The SharePoint Guidance [SPG] ServiceLocator provides you with a ready-to-use implementation of a Dependency Injection container. However, be aware of the following restriction when applying the SPG ServiceLocator in a constrained Sandbox context: it is not possible to compile on-the-fly generated xml-serialization classes, which are required for administrating the service interface and implementation within the servicelocator typemappings.

The execution of code statement:

typeMappings.RegisterTypeMapping<IServiceContract, ServiceImplementation>();

resulted in the following exception inside ServiceLocator code:

Microsoft.Practices.SharePoint.Common.Configuration.
ConfigurationException: Error on serializing configuration data ---> Microsoft.SharePoint.UserCode.SPUserCodeSolutionProxiedException: Error on serializing configuration data ---> Microsoft.SharePoint.UserCode.SPUserCodeSolutionProxiedException: Cannot execute a program. The command being executed was "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe" /noconfig /fullpaths @"C:\Users\SPadministrator\AppData\Local\Temp\OICE_925B8D58-F6D1-4BB3-9E01-FCBB9D816D0B.0\wkdrltlt.cmdline".

Explanation of this behavior:

SPG ServiceLocator applies XML serialization to administer the typemappings for the service interface and service implementation class. .NET XML serialization approach supports JIT compilation of the required xml-serialization classes. The benefit is that you do not need to generate and deploy these xml-serialization classes, the XmlSerializer framework generates them on spot. However, to be able to do this assembly generation; the .NET compiler is needed. And when within the Sandboxed constraints, you are not allowed to use filesystem resources.
By doing a little ‘digging’ in the SPG runtime pipeline, I discovered that not even my own custom classes caused the runtime serialization error; it actually could be derived back to the following serialization:

new System.Xml.Serialization.XmlSerializer(typeof(
Microsoft.Practices.SharePoint.Common.ServiceLocation.ServiceLocationConfigData))

The solution is to make sure that the required xml-serialization classes are already available: either in the GAC for generic use, or also deployed in the sandbox. I opted in this particular case to deploy Microsoft.Practices.SharePoint.Common.XmlSerialization.dll in the Sandbox.

Tip - Generic robust approach for disposing both normal object as WCF proxy

Situation: a consumer object invokes a provider object to access functionality. The consumer operates against an interface to decouple it at compile-time from the actual implementation(s) of the provider side. The provider is runtime injected via Dependency Injection. After usage, the provider instance may have to be disposed, typical to release native resources (e.g. network or database connections). However, not all provider types need to have the IDisposable interface implemented. To prevent the consumer class from being cluttered with checks on IDisposable being implemented, I delegate this to an utility class in our framework. An example of the consumer usage is now:

In the implementation of the DisposableDecorator class the check is done whether the decorated/encapsulated object implements the IDisposable interface, and if so the Dispose method is propagated on to the encapsulated object. Simple, and it keeps the consumer code clean and focussed. However, when the encapsulated object is actually a WCF proxy, something special needs to be accounted for. The standard application of the using block may then result in an undesired effect. This occurs when an exception is thrown on the channel, putting the proxy in the Faulted state. When next trying to dispose the proxy, the closing of the proxy results in throwing a new CommunicationObjectFaultedException. The latter exception hides the original exception, which has put the proxy in the Faulted state. The solution is to first check whether the encapsulated object is a WCF proxy, and if so if it's communication state is Faulted. If that's the case, then invoke the Abort method on the proxy. Otherwise just maintain the Dispose propagation.

Dynamic updatable configuration in SharePoint list for Dependency Injection

Dependency Injection and Inversion of Control are 2 well-known and related design patterns to achieve flexibility and loose-coupling in your system architecture. Compile-time you decouple the consumer from the real provider(s) at interface level. At runtime the interface consumer is connected to a particular real implementation for the requested interface. The consumer is thus only dependent on the interface (= agreed behaviour), and transparent towards the concrete implementation. Dependent on situational factors, another implementation can be runtime provided to the consumer.

The responsibility for runtime instantiating and returning the correct particular implementation is typically delegated to a factory object. Multiple frameworks are available to provide a Dependency Injection (or IoC) container. Well-known are Spring.Net, Castle Windsor.

In a recent Proof-of-Concept I needed the flexibility to easily switch between different implementations of a service behaviour. Started with a stub when initially focussing on construction of the consumer (UI), followed by a variant with the business data stored in a SharePoint list in the local site, and finished with the ultimate version with the data stored in an external Lines of Business system, unlocked to the client via WCF. I prefer to name this plumping responsibility 'interface brokerage'. The signature of such a broker is simple:

I could have applied one of the available Dependency Injection frameworks. However, in this PoC evaluation I had some specific requirements which none of them seems to support all:

1. I want to be able to runtime change the configuration, and have this automatically picked up by the interface broker;


2. I want to share the same configuration entity accross multiple broker consumers (or rather, have only 1 single configuration entity to maintain);


3. Support different client contexts - SharePoint WebPart, WinForm, and also Silverlight control via the same interface broker implementation;


4. Be able to specify constructor parameters for the instantation of a service implementation (e.g. the name of WCF endpoint);


5. Be able to let the client access mode influence which implementation class is returned (for instance, to apply IsolatedStorage for the Silverlight control)
   

I decided to implement this specific brokerage functionality myself. And almost inevitable choose to apply a SharePoint list as configuration store. Benefits of this above a file based configuration are:

• It's possible to view and modify the configuration remotely within the browser; no need to have access to the server environment (is required to modify the web.config)


• Modification can be runtime determined and picked up by the broker (a web.config modification is also noticed, but results in a recycle of the application pool)


• Via the SharePoint List webservice the configuration can be accessed from any consumer context: SharePoint WebPart, WinForm, Silverlight [running at the client desktop], and even from non-Microsoft technologies like Flash, Java.

The following illustrations highlight the concepts of the resulting broker implementation:

  

Setup of the BrokerConfiguration storage

Example of a filled-in BrokerConfiguration

Code extract of reading in and parsing of the BrokerConfiguration

The essence of runtime determination + instantiating of requested interface provider (details and exception handling left out)

I hope that above gives you inspiration on the possibilities of utilizing the SharePoint functionalities within your system setup. Love to hear for what other system aspects one has applied the SharePoint functionalities...