I sat in on a breakout session today at the Progress Revolution conference on OpenEdge BPM and migrating existing OpenEdge applications to work with (Savvion) BPM. There are some new ways of doing this that are coming in OE 11 that we are not seeing in this session, but I’ve had a few conversations with people since my blog post yesterday and expect to have a more in-depth briefing on this soon.
Traditionally, in OE development as in many other application development environments, the business process and logic are built directly in the application, intertwined with the user interface and other components. This pre-SOA app dev methodology is pretty old-school, but I think that’s what we’re dealing with in considering a lot of the existing OE apps that have been in production for years: not only where they designed before multi-tiered architecture was generally acceptable practice, in many cases they may have been designed by less-technical business people who weren’t aware of these types of coding standards.
Now that Savvion BPM is integrated with OE, the plan will be that business processes will be made explicit in the BPM layer, and eventually much of the user interface will also be moved to the BPM forms layer, while the more traditional OE code will provide the services layer that is consumed by the process. This creates a more flexible and open service oriented architecture, allowing the BPM processes to consume both the OE services (currently with web services, but presumably with tighter couplings in the future) and services from other systems in an enterprise’s environment in order to orchestrate multiple applications.
If you were starting fresh with a new app, that would not be a significant problem: build your processes and UIs in BPM, build your services in OE, and you’re done. The problem, however, is the huge body of existing OE applications that need to start migrating in this direction. This problem exists far beyond the OpenEdge world, of course: those with legacy code and monolithic applications of any sort are having to deal with this as they struggle to become more service-oriented, and to integrate BPM as an overarching orchestration framework.
Brian Bowman, a Progress senior systems consultant, led this session and gave a demo of creating a process in BPM – all the while explaining some BPM basics to what I assumed was a room full of OE developers. Like a huge portion of the business/IT world, most OE customers and partners have no idea what BPM looks like or what it can do for them, meaning that Progress has a lot of education to do before anyone actually starts integrating BPM into their OE apps. A huge opportunity for Progress, undoubtedly, but also a huge challenge. I’m also struck by the idea that a lot of the Progress people, particularly the SCs who will be demoing this to customers and partners, need to have some better general process modeling training including a bit more stringent BPMN education, not just training on pushing the mouse around in the BPM tool.
Brian was joined by Sandy (I missed her last name), another SSC, who moved from Brian’s “business analyst” role who created the process in BPM, to a “developer” role in OE. She had a pre-built OE app that had a button that instantiated a process and displayed the process ID; she showed the underlying OE code, which made a CreateInstance call followed by some updateDataSlot calls to update the parameters in the process instance with the OE database parameters. The rest of the integration happened on the BPM side, with the basic points of integration as follows:
- Create a process instance from an OE app, and populate the data fields. I don’t know OE code, but it appears that it uses a couple of new or repurposed functions (CreateInstance and updateDataSlot) to call BPM.
- Call an OE function from a process step using a SOAP call. This requires that the function be exposed in OE as a web service, but BPM would not have had to be changed in order to make the call, since that’s a standard functionality in Savvion.
- Update the OE database from a process step. This is based on the OE database connectivity functionality that has been added to BPM.
- Embed a WebSpeed form page in a BPM UI form: basically, replacing a BPM UI form with an existing WebSpeed form to complete a BPM step. It is not possible to use an existing OE GUI form in this way, only a WebSpeed form since the HTML can be embedded as a URL. This is done by embedding the search parameters directly in the URL that is called to invoke the embedded WebSpeed form, which may be a security concern in some situations.
There’s definitely an issue with those using the OE GUI (again, I’m not that familiar with OE, but I assume this is a thick client UI) since these can’t be used directly as BPM task UIs as you can with the WebSpeed forms, although you could add API calls to your OE GUI application to update the BPM process instance, effectively creating a shadow process in OE and BPM. Not best practice, I’m sure, but possibly a stop-gap measure for those migrating from the OE GUI either to WebSpeed forms or BPM UI forms.
OE and BPM have separate servers (as you would expect), and deployment is done independently, as far as I can tell. That makes sense, since the eventual goal is to have OE becomes more of the services layer consumed by BPM; there is no real need to have the deployment tightly coupled although you do have to be concerned about dependencies, as you would with any SOA deployment.
Some of the questions at the end were related to how OE functionality would be replicated in BPM, such as roles and security; Progress definitely needs to do some work around educating the customers and partners on how the features that OE developers currently rely on will be done on the BPM side, for those functions such as UI and work management that are expected to move over to this new environment.