Sunday, September 30, 2012

Beware with BCS Filter on non-nullable types

Application scenario:
  • ‘query’ operation in external system with one or more import parameters; with default values
    • Examples: SQL dynamic query or stored procedure, SAP Remote Function Call, SAP Gateway Service, WCF web service;
  • ‘query’ operation exposed via a BCS::Finder method; each of the import parameters mapped to BCS Filter parameters
  • SharePoint view on the ‘query’ result; e.g. via ExternalList, Business Data List, custom webpart
In such an application context you might experience that when you (on purpose or by accident) do not enter concrete values for the Filter parameters, SharePoint retrieves + renders a different set of external items as expected. You would expect the native ‘query’ operation to apply its default value(s). However, this is only true when the types of the import/filter parameters are nullable. If not nullable, SharePoint is required to submit a concrete value when invoking the Finder method. If missing from front-end invocation, SharePoint will submit the default value for the non-nullable type. E.g. for a DateTime, this means the value ‘1-1-1900’.
You have 2 options to alter this SharePoint BCS invocation behavior:
  1. In the BCS Model, declare the non-nullable types as nullable.
    <TypeDescriptor TypeName="System.Nullable`1[[System.DateTime, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]]" Name="IV_SEARCH_BEGDA" AssociatedFilter="IV_SEARCH_BEGDA">
  2. In the BCS Model, search for a method parameter with name "<filter-import-parameter>Specified". If present, make sure it’s default value is set to ‘false’.
    <TypeDescriptor TypeName="System.Boolean" Name="IV_SEARCH_BEGDASpecified">
            <DefaultValue MethodInstanceName2="Find_ExternalItems" Type="System.Boolean">false</DefaultValue>

Friday, September 14, 2012

OData service support in Duet Enterprise - 2.0 and 1.0FP1 SP3

SAP NetWeaver Gateway 2.0 has within the SAP architecture the role of transparent integration layer to the SAP Business Suite:
Duet Enterprise is a consumer of the SAP Gateway layer, Sybase Unwired Platform is another consumer for Mobile devices. The access through Gateway is based on current interoperability standards: W3* (SOAP / WSDL) Web Services and OData services (REST protocol).
In the current Duet Enterprise 1.0 FP1 product OData support iswas missing. The direct explanation is that SharePoint 2010 BCS does not support OData consumption. For Duet Enterprise interoperability it is was therefore necessary to unlock SAP data via the SAP Gateway Generic Channel. Sybase Unwired Platform since version 2.1 does have OData consumption support.
From the market (partners, including The Next View, and customers) is urged to include OData support in Duet Enterprise. Main limitation is, however, SharePoint 2010 BCS.
In SharePoint 2013, BCS supports OData consumption. And Duet Enterprise 2.0 can therefore also support the interoperability via Gateway OData Channel. Integration via Generic Channel continues to be supported, in terms of design-time and runtime.
SAP Gateway includes generator tools for Generic and OData channel. Both are subject to the restriction that SAP hierarchical data structure is not supported (no mapping capability). In case of hierarchical data it is possible to 'handcraft' the Gateway service in ABAP code. The programming model for custom OData providers is thereby a lot simpler compared to that for Generic Channel services.
XML Funneling architectural pattern, via which we still have the opportunity to utilize the benefits of the Gateway generator tools.
SAP and Microsoft have recognized that (potential) Duet Enterprise 1.0 FP1 customers, now want to connect to the future OData option of Duet Enterprise 2.0. For example, to reuse the same Gateway service for Mobile channel and SharePoint / Duet Enterprise. To make this possible, with Duet Enterprise 1.0 SP03 (released today, September 14) an OData-SOAP Bridge is included. In short this Bridge maps OData-based output of Gateway OData services to SOAP services, which then integrate into SharePoint 2010 BCS. The OData-SOAP Bridge is restricted to 'flat' SAP data structure, data-retrieval of complex SAP structure to SharePoint is thus not possible.
In Duet Enterprise 2.0 the OData-SOAP Bridge is not included; SharePoint 2013 BCS itself can directly consume OData.
  • Duet Enterprise 2.0 requires SharePoint 2013
  • In Duet Enterprise 2.0 the OData + Generic channels are supported; SharePoint 2013 BCS can consume OData services
  • For Duet Enterprise 1.0 a OData-SOAP bridge is available via SP03 to bridge Gateway OData services for consumption as SOAP web service in SharePoint 2010 BCS
    • Application of the Bridge is restricted to flattened SAP structure; in reality SAP data often has a hierarchical / complex structure (e.g. SAP LSO)
  • SAP advice on the interoperability endpoint decision: OData Channel or Generic Channel?

Saturday, September 1, 2012

User-centric Development Process for Duet Enterprise projects

In essence, a ‘Duet Enterprise custom scenario’ development project is not different from other application development projects. The customer – either the real end-user, or product management for package software -, has an idea about what to achieve and functional + non-functional (quality) requirements to underline the idea. Often this idea is still vague, and the requirement set far from complete and on aspects also contradictionary. The waterfall approach to yet start with application development (specify, build, test) typically ends up with wrong or failed end-results: the application does not live up to the real customer needs and expectations, and the budget is largely overrun as consequence of responding on the requirements changes. The agile movement came up to improve on this bad practice. Central is the structural involvement of the user (representative) during the full course of the development project. Continous, the user is in the lead about the specifics and the behaviour of the application functionality to be delivered. In Scrum, this responsibility is formalized within the product owner role.

Application mockup

A proven approach to enable the product owner to validate, correct, and ultimately confirm the application functionality is by make it experiencable, ‘touchable’. Provide the product owner with a realistic impression of the application behavour + feature(s) that the project will build: a clickable prototype / mockup.
Based on multiple positive experiences (also within non-Duet Enterprise project, e.g. BI Dashboards), we strongly believe in the added value and power of application mockup. We regard the role of UX / UID expert crucial for customer involvement, and thus for delivering the correct application functionality.

Meeting of 2 worlds

Yet, a Duet Enterprise project also is very much different from ‘normal’ projects. The cause lies with the meeting of 2 very different environments: IT technology, platform concepts, and human nature. The tradional SAP environment is transaction oriented, with focus on structural business process executions. The Microsoft environment, and in particular SharePoint, is far more loose. Ad-hoc processes are the norm, the individual user decides how to perform a specific (business) action. When these 2 worlds + thinking come together in a Duet Enterprise project, the first outcomes are often dramatic. SAP versus SharePoint architects, business analysts and developers do not understand each other (concepts). Both ‘parties’ disagree on how and where (that is, on SAP or on SharePoint side) custom development should be done. The personal preference on how to achieve the SAP+SharePoint integration is influenced by one’s own technology frames and familiair concepts. This has the risk that the user is forgotten: the user interests must be central, deliver an optimal user experience.

Align through Blueprint Duet Enterprise scenario’s

To break through this, we utilize in our Duet Enterprise development process a blueprint step with the focus exclusive on the Duet Enterprise specific scenarios. This blueprint is derived and agreed by a mixed group of SAP and SharePoint representatives. The goal of this step, and its endresult, is to come to a mutual understanding of the solution direction for each of the Duet Enterprise scenario’s. Self-employed constraints are to stick as close to the standards of both the SAP business package and SharePoint platform. Where feasible, we do allow custom development. Here we apply Duet Enterprise integration patterns that we have identified and defined: Consumer-oriented, Provider-oriented, and XML-Funneling pattern.
Of course, the discussion and preferences about where to make custom adjustments still manifest within the Duet Enterprise blueprinting step. However, as it now has the full focus of all involved, mutual agreement is earlier and more effective reached. This is the so-called ‘workshop effect’. Also, in this focussed approach, comparable application situations are easier to recognize. And where so identified, the earlier agreed solution approach can be reused. Starting point for the blueprint derivation is the User Interface Design as validated and confirmed by the product owner.
In the blueprint we derive and define per identified Duet Enterprise scenario the following pieces:
  1. Global descripion of the scenario: screenshot of the mockup screen and textual explanation. The purpose is to facilitate on high level a common understanding of the functionality in the scenario. There is no intend to compete with or replace use cases.
  2. Derivation, explanation and justification of solution direction. At minimal explanation of the proposed solution direction. But whenever applicable, also the rationale of why an alternative solution direction is dropped.
  3. SAP / SharePoint interface
  4. SAP Gateway datamodel(s)
  5. SAP building blocks: standard RFC’s, BAPIs; identification of needed custom SAP building blocks
  6. SharePoint building blocks: standard and custom webparts, SharePoint Service Applications, …

Blueprint validation by Design Authority / Authorities

Justified mantra nowadays within SAP and Microsoft IT departments is to avoid unnecessary or otherwise avoidable custom development. Instead stick close to the standard delivered functionalities of both landscapes.
It is also evident that fully excluding custom development is not feasible when you are developing company custom scenario’s.
We facilitate the consistency and continuity in the Duet Enterprise solution directions by confirming the blueprint to Duet Enterprise Rules, Conventions and Guidelines. The Design Authorities of both SAP and Microsoft IT departments validate the blueprint against these agreements. Derivation can be allowed, but requires the formal approvement of the respective Design Authority (SAP, Microsoft, and in some cases both).

SAP + SharePoint realizations based on the blueprint

With the blueprint accepted and delivered, from here on SAP and SharePoint teams in the project can start with their own development activities for the Duet Enterprise scenario’s. Since representatives of the teams were involved in deriving the blueprint, the concrete software design + development can be done relatively independent of the other party. Of course the data contract details of each SAP / Duet Enterprise interface are input for the SharePoint consumption. Regular sharing the SAP design with the SharePoint developers can achieve this.

Duet Enterprise Development Process

Business analysis
Business Analyst
Business representatives
Business vision
UID / UX expert
Business representatives
Business Analyst
Style guide
Duet Enterprise Solution Architect
SAP Business Analyst
SharePoint lead
Duet Enterprise Rules, Conventions, Guidelines
SAP Business Analyst
SAP developer
SharePoint developer
Duet Enterprise Solution Architect
Duet Enterprise Rules, Conventions, Guidelines
SAP developer
SAP Build – Rules, Conventions, Guidelines
SharePoint developer
Duet Enterprise Solution Architect
SharePoint Build – Rules, Conventions, Guidelines
SAP developer +
SharePoint developer
Operations – Rules, Conventions, Guidelines,