This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Expert advice: Working with SOA BPM, BPEL: Read more in this section
- How to solve common BPEL problems
- How to think of business design and transformation
Explore other sections in this guide:
Business process execution language (BPEL), a stalwart in the SOA world, hasn't undergone many changes in the last few years. While developers can appreciate the stability it offers, they can also run into common problems that dog even the most seasoned developers. While some of the road bumps may be standard SOA issues, others are particularly sticky in BPEL, and require planning before implementation, according to experts.
Problems with BPEL can be divided into two categories: technology issues and process issues. These often converge, particularly when business processes don't line up with the BPEL model, according to Vaughn Bullard, founder and CEO of Ashburn, Va.-based consultancy BuildAutomate Inc. This results in needing to custom code processes to fit the BPEL model.
You need a lot of rules when you're implementing any kind of SOA, BPEL included.
founder and CEO of BuildAutomate, Inc.
"I've had customers -- because BPEL is a buzzword -- who thought that BPEL would be a panacea for business process problems," Bullard said. This resulted in expensive, extensive custom coding. To avoid that, he recommended examining processes to ensure they're compatible with BPEL before beginning an implementation.
Not standardizing processes can also cause BPEL issues, causing an end result very different than what the business envisioned, according to Nauman Noor, a New York-based management consultant. Rationalization and re-engineering needs to be done up front -- rather than capturing the processes as-is -- to ensure that whatever is being automated is the end state envisioned by the business, he said.
Another issue more related to processes than BPEL itself is security and defining role-based and service-based access. "You need security when implementing BPEL," Bullard said. These policies need to be appropriately defined and implemented so that when a process executed by a user calls up another process, the user can access the second process without issues, he added.
Service-level agreements (SLAs) and enterprise service management and governance, which create accountability, are also critical for successful BPEL implementations, Bullard said. "If you try to implement BPEL without enterprise service management … you could have processes hanging without you knowing," he said. SLAs are also critical, as companies will need a guaranteed level of service between processes to ensure availability, he added.
Dangling processes and dependencies can derail business process execution language
Meanwhile, typical issues in technology can derail the best-intended BPEL implementations.
For example, dependencies on sub-processes can cause problems if the sub-processes don't terminate, Bullard said. "If they're not coded correctly, [the sub-processes] will sit there and hang," he said. One of the key ways to prevent hanging processes is to ensure strong enterprise service management is in place, he added.
Dependencies on non-Web service components can also throw monkey wrenches into BPEL deployment, according to Bullard. "If you're interfacing with a non-Web service-based system and waiting for processes to come back … it's basically business processes that don't fit the BPEL model again," he said. "You need a lot of rules when you're implementing any kind of SOA -- BPEL included."
The solution architecture can also be a source of concern, according to Léon Smiers, solution architect at global consulting firm Capgemini. A difficult layering architecture, complex integration or heavy load processes are best handled in a database or with common business-oriented language, he said.
More on business process execution language
Co-evolution of BPMN, BPEL drives BPM in SOA
How to invoke Java code from BPEL
Developers also need a data model before beginning a project, Smiers said. Often, they discover they don't have an appropriate one too late and are unable to integrate systems because the systems themselves aren't ready for integration.
"You need to have some kind of Esperanto across the application," Smiers said. "If you have a stable data model, it's easier to create BPEL-type processes." Having a data model prior to implementation also saves time if the data model needs to be changed later, he added.
Since the trend for BPEL is to reuse it, experts also advise developers to logically describe workflows to aid or assist in reusing code. "The workflows have to be componentized appropriately [and written] with an eye toward modulization," Noor said. He advised that, if the developer thinks there will be a common component or library, to sketch out the workflow first, then refine as it's developed. This extra effort can save time in the long run because it allows developers to reuse components, he added.
Finally, because BPEL tools vary by vendor, developers can't expect interoperability across vendor tools, Noor said. Any company that wants to switch vendors will need to convert the workflows to work with the new tool, he said.
The common thread that runs through these tips is to plan ahead before embarking on any journey with technology, even the tried and true ones like BPEL. Examining processes, creating data models and getting firm enterprise service management and SLAs in place goes a long way toward heading off BPEL problems as they pass.
Christine Parizo is a freelance writer specializing in business and technology. She focuses on feature articles for a variety of technology and business-focused publications, as well as case studies and white papers for business-to-business technology companies. Prior to launching her freelance career, Parizo was an Assistant News Editor for searchCRM.com.