Skip to Content

I wrote couple of blogs in the past

 

1. Qualities Required for a Successful Enterprise Mobile Solution

2. SAP Sybase Co-innovation Platform for Enterprise Mobility

 

In the second blog, I wrote a brief introduction to the responsibility separation between SAP and Sybase components so that power of enterprise and mobility are integrated seamlessly.  There were few questions around multiple boxes and overlaps.  In this blog I am trying to give the next level of details to explain the core problems solved by Data Orchestration Engine (Server component of NW Mobile 7.1) that is used in the SAP Sybase co-innovation platform.

 

Recap on Responsibilities

DOE Responsibilities

  • Business data responsibility determination
  • Business data integrity
  • Business data synchronization with delta handling and multiple version handling
  • Business information direct access (like opportunity lookup)
  • Server side programming model and development/customizing environment

SUP Responsibilities

  • Native application & application development infrastructure for client
  • Messaging and connectivity to the device
  • Device management
  • PIM synchronization

Joint Responsibilities

  • End-2-end lifecycle management for deployment, version control and trouble shooting
  • End-2-end integrated application dev and customization programming model

 

Capabilities Provided by DOE

Table below provides the core problem solved by DOE in this SAP Sybase Co-innovation Platform for Enterprise Mobility.  Essentially DOE helps in provisioning enterprise business information in the context of mobility world.  Provisioned information is then utilized by the device centric world and embedded in the context of mobile usage.  This component tackles mobile related technical challenges for accessing business information from a OLTP and OLAP systems.

Solution Quality

(Information access relevant)

Required Capability

(that is provided by DOE)

Seamless offline / online

  • Responsibility determination (who needs to get what based on rules and dependencies)
  • Keep the device in sync with required data in near real time (Inserts, updates and deletes to remove unwanted data)
  • Transparent connectivity for both asynchronous and synchronous access – Unified programming and configuration models
  • Data integrity handling – Conflict detection and resolution, error compensation, Key mapping, referential integrity

Efficient bandwidth utilization support

  • Solve the data integrity side effects created by local caching on the device (keep information in sync, conflicts, Asynchronous confirmation/rejections to local modifications, key mapping etc.,)
  • Only relevant modified data (at field level) needs to be synchronized and needs to be push based (end to end event driven)è Maintains the inventory of who has received what, then only delta detection is feasible without adding load on backend

Flexibility: Model Reuse across multiple scenarios & customizable pattern based data push

(Sample Scenarios)

  • Flexible time window based distribution (E.g. Activities within the time window of 10 days before and 10 days after) – Critical for supporting small devices due to memory constraints and its usage pattern
  • Flexibility in organizing the workforce (E.g. Switching from territory based sales force to product line based sales force should be flexible and fast) – Will result in realignment of data with relevant deletes and inserts (Otherwise impacts bandwidth utilization as well)
  • Fast realignment of data in case of business process change – Needs to know who has got what data
  • Model re-usage for different scenarios è Entity that is created once can be used in different applications without re-development with versioning support

Lifecycle management support for business data and process for enterprise mobility

  • Support for rollout, recovery of data without putting load on backend
  • Support for phased upgrade – Multiple version handling for messages and data
  • End to end support for monitoring and troubleshooting
To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Ganesh Kumar Palaniappan
    Hi Rampi,
    Thanks for ur Blog.
    Have seen SUP Server architecture indepently, having working DOE, Have few questions the way compenents will be interacting

    1) Role of Cache Data for SUP with DOE Integration, will be subset of data stored in CDS and Cache Database of SUP
    2)Filtering: We have Distrubution Model in DOE on writing business rules for distribution, we have filtering module of SUP, How data will be send from DOE will further will be filtered by SUP Filtering rules?
    3)In Terms of Devices data distribution:
    In terms of roles device management is with Sybase SUP architecture, in terms of data distribution, replication and reallignment based on business rules in DOE, how it will be interacting with Sybase SUP? How the subscription of device will be transferred to SUP? Do we have device level syncronisation between DOE and SUP?

    Looking for ur kind response in terms of integration questions, which will help us to understand how both the servers interact.

    Thanks.
    Reg,
    Ganesh

    (0) 
    1. Ramprasadh Kothandaraman Post author
      Hi Ganesh
        Thanks a lot for these questions and i am sure these questions would be there in many people’s mind.  Here are the comments to three points
      1. In case of DOE – SUP integration, SUP’s CDB is not used.  SUP queues the messages that are pushed by DOE and SUP delivers them to the device in a secure way.  In essence runtime of SUP would be messaging and connectivity in this integration
      2. In this integration filtering is done by DOE only and SUP delivers the sync message created by DOE to appropriate device.  SUP does not do any filtering calculation
      3. There is a one to one binding between SUP devices/subscriptions to the DOE end point (receivers).  DOE receivers are automatically created based on subscription from client or through business information like employee in the backend system.  DOE takes care of complete data handling to these receivers.  Device management (like software installation, patches, security on the devices) are all done by Afaria.

      Hope it clarifies

      With warm regards
      Rampi

      (0) 
    1. Venkata Subramani Renduchintala

      Hi Shrikant,

      DOE is not SAP MI.

      SAP MI is a mobile infrastructure provided by SAP earlier to SAP NetWeaver Mobile 7.1

      Typically, erstwhile SAP NW04 mobile stack (aka SAP MI 2.5) and SAP NW04S mobile stack (aka SAP MI 7.0x) are known as SAP MI.

      DOE is part of SAP Netweaver Mobile 7.1 or higher. It is the component responsible for data distribution and application provisioning.

      Hope this answers.

      Regards,

      Venkat

      (0) 

Leave a Reply