Organizations large and small routinely face challenges in managing business processes. From an administrative standpoint, policies and procedures are put in place to ensure compliance. However, no matter how strictly they are enforced, there are always those who work outside their boundaries.

The Fuego BPM solution helps organizations address compliance issues and business process modeling by providing a truly business-centric tool. It also provides the integration capabilities to participate effectively in a service-oriented architecture (SOA) through its native support for Web services, Java, CORBA, and XML technologies, among others.

Process Modeling and Development
Fuego Studio is the development environment for the Fuego BPM solution. Modeling business processes in this environment is very easy. Anyone who has worked with or created a swim-lane diagram in the past will be able to model processes in Fuego Studio. As shown in Figure 1, a very simple business process has been modeled for handling the application process for prospective candidates in a company. Activities are organized into swim-lanes identifying the owner role of each activity. The model illustrated in Figure 1 contains two roles: Candidate and Hiring Manager. Swim-lanes that have no title contain activities processed by the system only. For the purposes of clarity, Fuego Studio provides annotation capabilities that may be used to describe unlabeled swim-lanes.

For the purposes of this article, the business process modeled in Figure 1 is as follows:

1. The job candidate fills out a basic form using the provided Portal Web application requesting their name, e-mail address, postal address, and a text version of their resume.
2. The address of the candidate is validated against an external Web service. If the address is not valid, candidates are notified that they must update their information. If the address is valid, the candidate's data is passed to the Hiring Manager for review.
3. The Hiring Manager reviews the candidate's information using the provided Portal Web application. If the Hiring Manager does not review the candidate's application within one day of receiving the application, a reminder is sent to the Hiring Manager. Once complete, a notification of the Hiring Manager's decision is sent to the candidate via e-mail.
4. If the Hiring Manager decides to hire the candidate, the Process Paperwork action is executed to bring the candidate on board and the process ends. If the Hiring Manager decides not to hire the candidate, only a notification is sent and the process ends.

For the business process modeled in Fuego, the next step is to define and develop the supporting code for execution. By allowing process modeling to take place independently of code development, Fuego allows different constituencies to focus on the components of the model that are relevant to their expertise.

Defining and developing the supporting code for process execution involves the following basic steps:

• Establishing the system variables to contain process instance data
• Cataloging external resources and APIs to integration touch points
• Building user interfaces for collecting input from participants
• Writing the necessary code to manage the process

Web Services Integration
Integrating Web services into a business process model in Fuego Studio is very straight forward. As mentioned previously, the candidate's address will be validated against an external Web service. To make this service available, it's added to the catalog (a collection of tools, libraries, and services available to Fuego at design time and runtime).

Adding a Web service to the catalog requires the developer to import a WSDL document using a wizard. The developer identifies the location of the WSDL document and specifies a module name that will contain all services identified in the WSDL. The result is a set of the following objects.

• Fuego Component: Contains the Service Names defined in the WSDL document and all supporting data types
• Fuego External Resource: Definitions that identify the host of the Web service
• Fuego External Resource: Definitions that identify the relative paths on the service host to all services contained within the WSDL document

Logic in Fuego is written in a simpleto- understand language that hides the details of the service invocation. XML documents participating in the Web service call are structured in an object hierarchy, thus making the contents of each document available using standard dot notation. In Listing 1, all variables prefixed with "i_" represent instance variables available to all activities through the life of a given process instance. The variable prefixed with "l_" is a locally scoped variable available only within the Check Address Activity.

The code in Listing 1 is just an example of the capabilities of the processing available in an activity. Additional sophisticated options exist for handling the required logic, routing processes, and interacting with external systems.

Summary
Fuego's BPM solution and the Fuego Studio provide a business-process modeling environment that focuses on business first. By using the swim-lane diagram as its design interface, it allows the key stakeholders with the process knowledge to work with the tool without requiring a technical skill set. Developers may then focus on creating the supporting code and integration touch points to support the true business need. And with its strong integration capabilities, Fuego fits well into an SOA. Overall, Fugeo's BPM solution is a good approach for tackling business-process modeling.

Company Info
Fuego
2400 Dallas Pkwy Suite 350
Plano, Texas 75093
Phone: 1 972-801-4200
Fax: 1 972-801-4201
Sales, U.S. & Canada: sales@fuego.com