IoT SAP SETU Middleware Integrated Approach
0 likes21 views
The document discusses the SAP-Setu approach for integrating and customizing physical business processes with system processes in SAP applications. It highlights the Setu's capabilities in consolidating various Automatic Identification and Data Capture (AIDC) devices and handling multivariate data, while enabling seamless synchronization with SAP's business processes. The advantages of Setu include its flexibility, reduced resource demands for physical enablement, and opportunities for enhanced composite applications within the SAP ecosystem.
IoT SAP SETU Middleware Integrated Approach
- 1. Know…Now! SAP-SETU Approach and Advantages
- 2. Current Scenario Ent Apps Bus • Multiple vendors, both traditional (one pipe per device) and emerging (unified data pipe) exist, addressing a part of the physical process • Disparity in Physical Business Process and System Business Process is not yet bridged
- 3. Current Scenario •Partial, piece-meal approaches (eg., AII) only lengthen the process without addressing the core need • SETU presents an easy, elegant, quick-to-market approach addressing the same
- 4. SAP-SETU Approach XI SAP Web AS R3/mySAP Biz Suite/x-Apps/3rd Party Apps Uniform, correlated, singular data pipe to all AIDC devices / Sensors through SETU Other Components Business Contexted, App specific data to PHYSICAL ENABLE the Apps Impact of WAS hosted SETU SAP Web AS Disparate, non-uniform 3rd party patches to AIDC devices /Sensors Other Components Other mySAP NC-R3 3rd Party my SAP SCM R3 XI Physical Biz Process in sync with System Process. Maps with XI BPM, EP WF and WAS Biz WF Without SETU
- 5. SETU - Introduction • SETU consolidates various AIDC devices (including industrial automation – PLC etc.,) – Not just serialized data but also multivariate • (serialized data of BC, RFID, non-serialized like UBW, Wi-Fi, Triangulated, multi- coordinate data like RTLS, GPS, multi-variable data like GPS or sensors) – In-Memory data processing • SETU adds business context in terms of PHYSICAL BUSINESS PROCESS – Process definition as per global standards – Van der Aalst patterns and BPEL4WS • SETU handles EPC-centric AND non-EPC centric data as EPC is restrictive on non-retail domains – RP AND Non-RP – ALE AND Non-ALE – Thus SETU works with non-EPC feasible devices also (e.g, a unique EPC Code for triangulated location within my warehouse? For data from a microcontroller? Or a globally unique seat number for a flight?)
- 6. PHYSICAL vs SYSTEM BP • SETU BPM is customized for PHYSICAL business processes – SYS Proc Def: • Receive PO – Pick and Pack – Ship – Instance • One SPECIFIC PO received, 10 SPECIFIC items picked and ONE parcel shipped – PHY Proc Def: • Receive PO – Pick and Pack – Ship – Instance • One SPECIFIC PO received • 10 SPECIFIC items picked – Each action of picking ONE item creates ONE INSTANCE in the BP. So 10 INSTANCES of ITEM MOVEMENT • ONE parcel shipped • The life cycle of PHYSICAL Items, as per physical process is different from that of SYSTEM process • Only a focused approach in PHYSICAL Process will track the Physical objects throughout the process effectively, thus also enabling many physical-level controls – Eg., ISO Process enforcement, KANBAN enforcement, FIFO etc.,
- 7. How SETU maps to SAP • SYSTEM Business Process defined in SAP (XI-BPM, EP WF or WAS Biz WF) • PHYSICAL Business Process defined in SETU • Map the relevant Data Points in SETU BP to any SAP BP • Instantly PHYSICAL ENABLE the SYSTEM Business Process in SAP • E.g., a specific process in mySCM, SAP Retail application, any xAPP, any CAF built app • Physical enabling is a time and resource consuming exercise – as it needs custom building of the above system processes using AIDC devices (even in the presence of AII in case of RFID) – e.g., Adaptive mySCM took @ 2 years)
- 8. SAP-SETU Bridge • SETU BPM is customized for PHYSICAL business processes • SETU’s deployment on SAP WAS allows for easy integration and smooth transitions between PHY and SYS processes • The process mappings in SETU and SAP are synchronized through XI • All front-end activities are synchronized through EP • SETU exposes granular functionalities as web services that can be tapped at various levels (raw-data, physical contexted data, business- contexted data, Events, Alerts, EPC RP filtered data, EPC ALE/IS filtered data etc.,) • Based on correlation between PHY and SYS process definitions, SETU services can be tapped to trigger events in the SYS process (i.e, any SAP BPs) • Physical (SETU) process definition follows industry standards – so can be exported to 3P engines and vice-versa
- 9. SAP-SETU – Phase 2 SAP Web App Server S E T U mySAP SCM mySAP CRM mySAP SRM mySAP PLM R/3 X-Apps SAP Retail etc.,
- 10. SAP – SETU Possibilities “Physical Enable – Productize the access to business contexted data on the entire life-cycle of moving, non-moving physical objects” • Since SETU will be part of the WAS, users can Physical Enable ANY process of ANY component just as they build any composite app do using CAF • Each Process built so can be productized for more promising areas - eg., Physical Enable SAP Retail or mySAP SCM and various other possibilities
- 11. SAP-SETU Scenario 1 Physical Enable vertical application like SAP Retail Internal Warehouse Distribute Shelf-Life Sale Post-Sales Subscribe to Services Subscribe to /Pull from SAP Internal Warehouse Distribute Shelf-Life Sale Post-Sales Forecast/Replenish Physical Process – life cycle of Pallets, Cases, Items, Trucks, Forklifts, Employee Shift Cycle etc., System Process – Activities of Business Process Web Services exposing data at various levels - Raw data from devices, Physical Contexted data, Business Contexted data, Physical Events and Actions, Device Triggers etc., Process Def, Scenarios, Process Constraints, Master Data, Process Mapping from XI BPM, EP WF and WAS Biz WF etc., Step 1: Define Physical BP that covers the scenarios in System Process. Step 2: Define Data Points needed for each activity/step in System Process Step 3: Define level of depth and context for such data points (can also include other components like NW BI) Step 4: Map System Process to select Setu Data Services. Step 5: Auto subscribe to relevant Setu Services. PRODUCTIZE IF FEASIBLE.
- 12. SAP-SETU Scenario 2 Physical Enable a complex application built on CAF or an x-APP Subscribe to Services Subscribe to /Pull from SAP Physical Process Web Services exposing data at various levels - Raw data from devices, Physical Contexted data, Business Contexted data, Physical Events and Actions, Device Triggers etc.,
- 13. SAP-SETU Scenario 3 Physical Enable a complete business process (as in XI BPM) irrespective of the number of SAP components involved (R3/mySAP) Subscribe to Services Subscribe to /Pull from SAP Physical Process Web Services exposing data at various levels - Raw data from devices, Physical Contexted data, Business Contexted data, Physical Events and Actions, Device Triggers etc.,
- 14. SAP-SETU Scenario 4 Float any of the above as Service on a Cloud (e.,g Amazon CC) • Once such applications as above are productized, a number of easy-to-use services can be floated. Examples (many such services can target SME/Business One users): • Anti-Counterfeit • All connect points in a pharma supply chain can simply scan barcode/tag and automatically send the same to an Authentication Service hosted on a cloud, with immediate reply •This can be as simple as sending an SMS. Can be used by anyone (subscribed) • Warranty • A service center (e.g., mobile/electronics) can simply send an SMS to the service hosted by SAP but paid for by the OEM and service centers • A user can scan/photograph a barcode or number thru his mobile to check authenticity of any product. • Supply Chain • A customer / sales man in the field can check exact delivery status by SMS’ing PO Number - truck status by GPS and package status by UWB/RFID
- 15. How is this different from current solutions? • Current approach (AII) is Process Extensions based – eg., Inbound, Outbound, RTI etc., • Each Process set/ extensions has to be custom built and only then a process can be Physical Enabled, that too only for RFID/some AIDC and ONLY from EPC perspective • e.g., release of mySAP SCM RFID. This way, slowly all of the apps will be PE’d but it will take very long time and that too for frozen process steps only. What if a new x-APP or CAF calls for PE? Or what if the customer has a process different from the std? • Unlike this approach, SETU allows to build any Physical Process on the fly and map it to the System process of any of SAP components – so making all SAP apps more flexible, adaptable and extensible
- 16. Advantages • Allows the users to define ANY business process as per their requirement – Unlike the process extensions of R3 in AII • The process definitions can extend to any of the components of mySAP Business Suite and SAP Netweaver • The presence of Physical data with business context and access to the powerful components of mySAP Business Suite opens up many opportunities for building COMPOSITE APPLCIATIONS • This approach goes beyond RFID focused, EPC oriented solutions which needs large-scale customizations • An SAP Web AS hosted SETU can be become the default PHYSICAL ENABLING PLATFORM for any SAP component
- 17. Advantages… • SETU adds to AII:- The out-of-the-box AII process extensions apply only to standard SAP business processes (that too only in R3 and lately mySCM). For example, customized shipping solutions in SAP will prevent the enterprise from utilizing the out- of-the-box shipping solution built in AII • SETU approach increases the usage and thus ROI of Netweaver XI and other components, at a fraction of the cost of custom development for Physical enabling applications
- 18. How SETU Complements AII • Based on the outcome of the conf call on 12.3.09, this could be the summary on how SETU complements AII – SETU acts as • Device Driver and Controller • Physical Business Process Modeler – And Integrates through AII to SAP environment