appdev – Page 3

Smarter Processes With Kapow Integration

I’m in a Kofax Transform breakout session on Kapow Integration together with KTA; I missed documenting the first part of the session when my Bluetooth keyboard stopped talking to my Android tablet, until I figured out how to pair it with my iPhone (which is not supposed to be possible), so I’m blogging on that. I feel like Macgyver.

Kapow provides a method to create “robots” for a sophisticated sort of automated control and screen scraping of web pages, so that you can create robots to interact with a web page for the purpose of integrating it with other applications (such as those built on Kofax TotalAgility) instead of a user having to interact with the page directly. In the demonstration that we saw, a robot was created to enter data to generate pay stubs on a site, then scroll between the full set of stubs created to take a screen snapshot or PDF of each. This allows any web application to use the robots to harvest information from a web site without user interaction, for example, to go to a series of bank web sites and enter the provided credentials to gather bank statements as input to a mortgage process. The use case shown had a web application that was presented to the customer, gathered their credentials for a number of banking sites, then went to each of those behind the scenes to grab the bank statements using the robot’s knowledge of how to navigate to each of those sites. Although the web sites being remotely controlled are hidden from the user, the robot can show a clip of the underlying site to, for example, display an error message such as incorrect credentials.

The design is all pretty much drag-and-drop, meaning that a semi-technical data or business analyst could work through the creation of a robot: they just need to know how to navigate through the web site to be controlled, and be able to understand how to handle all of the possible error cases. There are more technical implementations for complex scenarios that would require developer skills, but a lot can be done without that.

In my past life as a systems integrator, we did a lot of screen scraping, mostly of green-screen systems that could not be easily integrated with; funny that we have exactly the same problem even though we have leapfrogged a few generations of technologies from terminal emulators to browsers. Plus ça change.

SAP’s Bigger Picture: The AppDev Play

Although I attended some sessions related to BPM and operational process intelligence, last week’s trip to SAP TechEd && d-code 2014 gave me a bit more breathing room to look at the bigger picture — and aspirations — of SAP and their business technology offerings.

I started coming to SAPPHIRE and TechEd when SAP released a BPM product, which means that my area of interest was a tiny part of their primary focus on ERP, financials and related software solutions; most of the attendees (including the analysts and bloggers) at that time were more concerned with licensing models for their Business Suite software than new technology platforms. Fast forwarding, SAP is retooling their core software applications using HANA as an in-memory platform (cloud or on-premise) and SAP UI5/Fiori for user experience, but there’s something much bigger than that afoot: SAP is making a significant development platform play using those same technologies that are working so well for their own application refactoring. In other words, you can consider SAP’s software applications groups to be software developers who use SAP platforms and tools, but those tools are also available to external developers who are building applications completely unrelated to SAP applications.

They have some strong components: in-memory database, analytics, cloud, UI frameworks; they are also starting to push down more functionality into HANA such as some rudimentary rules and process functionality that can be leveraged by a development team that doesn’t want to add a full-fledged BRM or BPM system.

This is definitely a shift for SAP over the past few years, and one that likely most of their customers are unaware; the question becomes whether their application development tools are sufficiently compelling for independent software development shops to take a look.

Disclaimer: SAP paid my travel expenses to be at TechEd last week. I was not compensated for my time in any way, including writing, and the opinions here are my own.

NetWeaver Process Orchestration Update At SAPTechEd

It’s been a busy first day here at SAP TechEd, although some of that in briefings that I haven’t yet fully digested, and I’m finishing off with an update on NetWeaver Process Orchestration from Alexander Bundschuh (from the PI side) and Benjamin Notheis (from the BPM side). The goal of Process Orchestration is to improve processes and save integration costs, and it includes a number of tools:

For customers currently running a PI and BPM dual-stack system moving to the consolidated Process Orchestration stack, they can reduce their operational footprint by running them both on the same platform but also improve performance and stability because what were previously web service calls between PI and BPM are now direct Java calls on the same engine. There are some good resources on implementing enterprise integration patterns in Process Orchestration, they discussed a number of techniques for the migration:

Migrating the ccBPM BPEL models over to BPMN
Designing integration flows graphically in the Eclipse
Using conditional process starts (for aggregator/correlation patterns where an inbound message event either matches with an existing process instance or starts a new one) which is a new feature in NW BPM,
Using the new NW BPM inbox for human-centric tasks, using either a traditional inbox view or a stream view, and providing features such as enabling users to manage substitution rules for their out-of-office times (note that this is for BPM only, and not a UWL replacement for BW tasks)
Integrated monitoring and administration between PI and BPM, allowing navigation from a BPM process instance to all associated PI messages, or from a PI message to the associated BPM process, plus graphical dashboards
End-to-end integration visibility to allow transactions to be correlated and tracked across systems, including B2B scenarios

Process Orchestration is available using HANA as the database (BPM can use HANA as a database, although there are no BPM-specific services available yet on HANA), although that was done for infrastructure simplification purposes and doesn’t show any significant performance improvement; in the future, further refactoring will exploit HANA capabilities fully and should show a greater performance increase. Also on their roadmap are technical error handling in BPM, and some improved B2B trading partner and intelligent mapping capabilities.

Good update, with lots of great information for customers who are using both PI and BPM, and want to bring them together on a common stack.

There a number of other sessions on Process Orchestration here at TechEd Las Vegas, as well as at the upcoming Amsterdam and Bangalore events, and a section of the SAP Community Network (SCN) on Process Orchestration.