Diff (diff 0.000 sec, rendering: 0.000 sec, diff len: 6 chars)
Fujitsu Computer Systems Corporation
Support Newsletter 15.0
Welcome to the fifteenth edition of Fujitsu Computer Systems Corporation’s quarterly Technical Support Newsletter, covering the Interstage suite of products. This newsletter is aimed to update our existing customers, as well as our Fujitsu affiliates and business partners, on issues of interest to the technical support community. This edition continues the broadening of our focus from the Interstage Business Process Manager, to the entire Interstage Suite, and is organized into the following three sections:
1. Product News :
The BPMN-XPDL-BPEL value chain
What’s new in CentraSite v2.1
What’s new in Interstage Business Process Manager Version 7.4
2. Tech Section – Support Tips, Answers, and Technical Articles
3. Customer Feedback Survey
I hope you find this issue of our Support Newsletter to be a valuable and informative
Tool, as you continue to use Fujitsu’s Interstage Suite as a key component in your business operations.
Sandia Yang
Senior Manager, Customer Support
Fujitsu Computer Systems Corporation
Aug 1st, 2006
Requests For Additional Information
For additional information on the Fujitsu Interstage Suite, please contact your regional representative at Fujitsu Computer Systems Corporation or email us at info@interstage.com. In addition, North American customers can request information via a toll-free line at (888) 248-9273
----------------------------------------------------------------------------------------
Upcoming Events
Gartner Symposium ITXpo 2006, Orlando, Florida
8 October - 13 October 2006 -Walt Disney World Dolphin
225 analyst-led conference sessions. The ITxpo showcase of breakthrough solutions. CEO Keynotes. User Case Studies. Analyst One-on-Ones.
http://www.gartner.com/it/sym/2006_/sym16/sym16_home.jsp
----------------------------------------------------------------------------------------------
Upcoming Interstage Business Process Manager Training Sessions:
Fujitsu Computer Systems Corporation conducts an Interstage Business Process Manager API Level Training Class every month at their corporate headquarters located in Sunnyvale, CA. The schedule for training sessions for customers in North America is listed below. Please contact your regional sales representative for enrollment details.
Course Dates:
2006 |
Dates |
Days |
Times |
August |
15, 16, 17 |
Tuesday - Thursday |
10:00 am - 4:00 pm, Daily |
September |
12, 13, 14 |
Tuesday - Thursday |
10:00 am - 4:00 pm, Daily |
October |
10, 11, 12 |
Tuesday - Thursday |
10:00 am - 4:00 pm, Daily |
The other Interstage Business Process Manager courses that are available and that are scheduled based on demand include:
If you would like to unsubscribe from this newsletter, or would like to provide Fujitsu with feedback, please e-mail me at:
Vivek Chandran
The Support Group
Fujitsu Computer Systems Corporation
Aug 1st, 2006
By Keith Swenson, Chief Architect and VP of R&D
I got a chance to participate on a panel session at the BPM Think Tank in Arlington, VA, on May 24 2006, on the subject of BPM Standards. Richard Mark Soley was on one end representing OMG and the BPMN standard. John Evdemon from Microsoft was on the other end representing BPEL for which he is the TC Co-Chairman. I was between them, representing XPDL from WfMC. The order was random (although Richard suggested we were ordered by height) but as it turns out this is a natural order of progression for use of these standards. Sandy Kemsley described this as the "BPMN-XPDL-BPEL value chain" in her post about that panel session. (ThanksSandy for the term!)
Many people today automatically assume that BPEL and XPDL are direct competitors. This is not at all true. BPEL and XPDL are entirely different things, for entirely different purposes. I will repeat that statement a few times here to emphasis it.
But first, a quick summary of how they are different.
BPEL is an "execution language". It is a programming language that has variables and operations. The operations can send and receive SOAP messages, and there is strong support for XML and XML transformation. It has constructs that make it easy to call multiple web services at the same time, and synchronize the results. It does not have any concepts to support the graphics of the diagram; activities do not have a position and size, and there is no representation at all of an "arrow".
XPDL is a process design format. It is a file format that represents the "drawing" of the process definition. It has X & Y coordinates and node size. It has a concept of lines, and points along the line that give it a particular path. The nodes and lines have attributes which can specify executable information such as roles, activity descriptions, timers, web service calls, etc. XPDL 2.0 contains extensions in order to be able to represent all aspects of BPMN (BP Modeling Notation). The goal is to be able to save and exchange the process diagram.
The goal of BPEL is to provide a definition of web service orchestration, the underlying sequence of interactions and the flow of data from point to point. Ultimately BPEL is all about bits and bytes being moved from place to place and manipulated. It does not however attempt to represent the drawing that you used specify the orchestration.
The goal of XPDL is to store and exchange the process diagram. It allows one process design tool to write out the diagram, and another to read the diagram, and for the picture that you see to be as similar as possible. It does not, however, guarantee the precise execution semantics. As you see, BPEL and XPDL are entirely different things for entirely different purposes.
The different usage is best represented in the diagram below. At the top are various design level tools. At the bottom are execution environments. XPDL can be used to carry the design from design tool to design tool. BPEL, XPDL or other formats might be used to communicate the executable process to the engine. Generally, a vendor specific design tool is necessary to translate the design into an engine specific format. Generally, it is not possible to take executable code from one vendor's design tool, and execute it in another vendor's engine. Even with BPEL, which many believe was for this purpose, does not at this time allow different engines to run identical copies of BPEL code.
The XPDL file can provide this design interchange because it offers one for one representation of the original BPMN process diagram; it can be written, and re-read to recover the original diagram. BPEL, on the other hand is a non trivial mapping which is widely recognized as being one directional: you can take a BPMN diagram and produce BPEL, but it is difficult or impossible to recover the original BPMN diagram from the BPEL. This is not surprising since it was not designed for process design interchange.
Process interchange is very important to customers who are investing a tremendous value in their process diagrams, and do not want to locked into a single vendor. (The vendors may desire this lock in, but never forget that the customers are paying the bill and have a choice.)
The importance of process design interchange will increase as the market matures. Currently, without design exchange, a single vendor must supply all of the tools that an organization might use. As the market matures, we can expect to find specialized tools that provide one function better than the vendor providing the engine. Or there will be people who are trained on a special tool and don't want to lose that skill to pick up a new vendor version. The result is that we see a complete ecosystem of specialized tools that all work at the design level. This might be depicted in the following diagram:
You might ask, if BPEL does not manage to communicate the execution representation to various engines with complete fidelity, why then would we expect XPDL to exchange the process diagram with complete fidelity? The answer is simply that is does not need to. One design tool does not understand the output from another tool completely, but every design tool will understand the most important parts (the form and shape of the diagram) as well as many standard BPM attributes. Because the model is communicated from design tool to design tool, if the transfer is not perfect, you have a chance in the receiving tool to fix it up. Not perfect, but both useful and pragmatic.
Not every tool needs to understand the complete diagram. A simulation tool for instance will use the standard parts of the diagram, but probably ignore things like the attributes that define web service calls, since simulation does not need to know this.
One of the most important aspects of XPDL is the extensibility mechanism. Each tool has specialized requirements on the diagram, it can represent these using extended attributes. Other tools will not understand these extensions, but they will carry the extensions along. Thus a tool specialized to clean up the layout, might manipulate the graphical aspects of the model, and return a cleaned up model including all the extensions back to the original source without losing any information. Enhydra JaWEfor instance is an open source XPDL editing tool that has been publicly demonstrated to read an XPDL file from Fujitsu's Interstage Business Process Manager, edit, and return it without loss of vendor specific extensions. JaWE even allows you to view and modify the extended attribute values.
Some execution engines take XPDL directly. Fujitsu's Interstage Business Process Manager does because it is workflow style BPM and it is important for human activities to retain their identity even while executing, so that run time modification and process migration can be readily supported. That is the choice that a particular engine makes. We presume that the more EAI-style engines will prefer BPEL.
These are the differences in the roles of these three important standards. Our sitting order on the panel was appropriate and fitting, because users will usually start by drawing a BPMN diagram, saving the partial diagrams as XPDL during development, and ultimately translating to BPEL for transmission to an EAI style BPM engine. These are three very different and very compatible roles. But remember: BPEL and XPDL are entirely different things for entirely different purposes.
By DeeDee Kato, Senior Product Manager
On July 11, 2006, CentraSite v2.1 was released. CentraSite is a Service Oriented Architecture (SOA) registry and repository, which allows you to manage and govern your SOA environment and to achieve control and transparency across all IT resources related to the SOA. It stores and manages web service descriptions and application integration models, as well as related SOA artifacts, including business process and information models. CentraSite also reports changes on these SOA items throughout their life cycle in the enterprise. Such a centrally located, extended SOA registry and repository is an important component that is necessary for any serious SOA implementation.
CentraSite benefits include:
Figure 1 shows an example of the AJAX-based interface called CentraSite Control.
Figure 1
As services proliferate and the applications that consume them get more complex, CentraSite reduces the perception of this complexity by helping you to quickly:
From a functional point of view, CentraSite manages metadata generated from integration software, web service descriptions, application specific data (XSLT, forms, etc.) and in general serves as a central store for documents in native XML and non-XML formats. WebDAV is used for storing and retrieving development XML artifacts in the CentraSite repository such as process definitions in XPDL, models, sequences and more. A JAXR-API is provided to interact with the CentraSite registry. The CentraSite registry/repository can be accessed using a browser-based interface (CentraSite Control) or an Eclipse-based interface.
Thus, you can deliver the cost-effectiveness of SOAs’ by utilizing shared resources, composing systems with associated legacy services, business process models and general transformation rules.
Figure 2 shows an example of the graphical impact analysis. Here, the BankLoan business process is calling 3 web services (eg. Employment Check, Credit Check, and Title Check). If someone tries to delete one of these web services, an error will indicate the association.
Figure 2
CentraSite restricts the access to stored SOA resources by providing a means for user authentication and authorization (also on instance level), and by logging all user activities and operations on CentraSite for later auditing. Thus, you maintain full control on how and by whom CentraSite and the resources stored therein were used at a specific point in time. All repository objects are versioned, so that you can retrieve older versions of any object as required.
CentraSite offers an extensible data model, so it is not limited to handling web services. You can also include and register custom generated objects and services to have them participate in SOAs’ in order to reap SOA benefits quickly.
CentraSite offers various interfaces such as UDDI, JAXR and WebDAV to its internal data model, as well as an API-based query interface.
Sophisticated reporting capabilities allow you to easily understand which services are available across departments, who uses them and what business values they offer. They help you analyze the impact of changes before they are applied to interrelated SOA resources managed via CentraSite. Extensive reporting about interdependencies between used SOA resources helps businesses better understand and control their operations and apply the right changes to their systems properly. The reporting capabilities are provided using BIRT (Business Intelligence and Reporting Tools) plugins for Eclipse.
Figure 3 shows an example of the CentraSite Eclipse-based Registry browser.
Figure 3
Figure 4 shows an example of the BIRT Report Designer in Eclipse.
Figure 4
Figure 5 shows an example of a report that shows the top 10 web services being used.
Figure 5
CentraSite v2.1 now comes in 2 editions:
CentraSite Community Edition
• UDDI v3.0 search using predefined metadata models
• Predefined reporting modules
• AJAX-based interface and the Eclipse Registry Browser
• Suitable for small to mid-size organizational as well as departmental use
• Available to all Sponsors and Members at no cost
CentraSite Enterprise Edition
• In addition to the functionality available in the Community Edition, it includes:
i. Customizable reporting modules
ii. JAXR interface with subscribe and notification capabilities
iii. WebDAV access to the SOA repository
iv. Extensible meta-data model for the definition of customer-specific SOA artifacts
• Suitable for large enterprises and cross-organizational use
• Available to all Sponsors and Members under commercial arrangements. For more information, please contact us at info@soaworks.com.
CentraSite provides out-of-box integration with Interstage Business Process Manager. Process driven integration is all about end-to-end BPM capabilities so business users have complete visibility into their business operations and can quickly respond to changes in their environment. SOA provides an excellent foundation for implementing process-oriented integration scenarios that solve complex business process management and orchestration problems.
Today’s BPM solutions provide a rich toolset that facilitates modeling and engineering business processes, while at the same time, leveraging services exposed as part of the SOA. SOA is becoming a key enabler for BPM, providing a flexible architecture that’s easy to extend and also capable of adapting to changing requirements. Through the use of SOA, BPM processes can be shielded from the underlying changes within the services infrastructure.
The following figures show the integration between Interstage Business Process Manager and CentraSite. Here, a Process Architect can easily search CentraSite for the appropriate web service (eg. Title Check Web Service).
Just as business processes can leverage the services within the enterprise, these same business processes also can be exposed as services to be consumed from within applications. The end result is that BPM becomes part of the SOA fabric, in which the business processes are viewed as nothing more than a new kind of service. If you are doing SOA, your design starting point should be what business processes you want to execute.
In Summary
CentraSite is an SOA registry and repository that manages the life cycle of enterprise wide service landscapes. It maximizes the governance and transparency of IT systems, the data created and used by them and the processes enterprise businesses rely upon, by allowing you to catalog related resources and analyze the impact of process changes.
For more information on CentraSite and the CentraSite Community, please visit www.soaworks.com or contact info@soaworks.com.
By Thomas Gronbach, Product Marketing Manager
Helping you reuse what you have – that is what a “Service-Oriented Architecture” (SOA) aims to deliver. The CentraSiteTM Community builds on this promise by bringing partners together to help you as a customer successfully design, implement, manage, govern and optimize a complete SOA ecosystem.
The CentraSite™ Community is a unique approach to:
Uniting partners to deliver standards-based, interoperable SOA solutions.
Learn more about the benefits of becoming a CentraSite Community Sponsor today.
Register to become a member of the CentraSite Community today.
Providing enterprise customers with a single destination for SOA best practices and the latest industry information by leveraging social media tools (e.g., discussion forums, blogs, wikis, RSS feeds, and more). The CentraSite™ Community’s rapidly growing coalition of partners is committed to delivering on the promise of SOA - interoperability and reuse. The aim of the community is to help enterprises in their endeavors to break down legacy, stove-pipe applications into modular components that can be leveraged across different business lines and units.
Once these core modular components are created, they can be reused in business processes or reassembled into composite applications that can then be executed on request by any system, regardless of the underlying operating system, programming language or geographic location.
However, you need a secure store for these reusable, modular components with the ability to easily search and retrieve these assets. A standards-based SOA registry and repository thus plays a key role in the development of business processes or composite applications that integrate business services across different platforms, lines of business and geographies within organizations. CentraSite™ , jointly developed by Fujitsu and Software AG, and continuously enhanced by the CentraSite Community Sponsors; represents the foundation of this Community and serves as the central store that provides you with visibility and control over your SOA assets.
Learn more about the CentraSite Community at www.soaworks.com.
By Amita Abraham, Product Marketing Manager
Interstage Business Process Manager Version 7.4 was announced on July 21, 2006.
The major highlights include:
Enhanced Studio for process modeling & simulation
InterstageBusiness Process Manager’s Studio helps bridge the process communication gap between business and IT professionals. It combines the power of Eclipse with the ease of use of a Visio-like environment making it the ideal environment for both business and IT to collaborate on process design. The advanced business process simulation capabilities built in to Studio let business users define and refine their business processes before they hand them over to their IT counterparts to be integrated with their enterprise’s back-end systems. And what’s more, you can even work on your business process models off-line and then share them with others online.
InterstageBusiness Process Manager’s Studio lets you create different scenarios for your business process. You can vary the number and kinds of resources and their associated costs for a particular process scenario, simulate the scenario, and then clearly identify potential bottlenecks in your process.
Simulating a business scenario helps identify potential process bottlenecks
Consider the case of a bank that wants to automate a manually intensive loan approval process.InterstageBusiness Process Manager’s Studio provides them with the environment to simulate their “as-is” business process that they already have mapped out, and compare the costs and resources required for this process to a similar process with steps that have been automated.
Comparing different simulated scenarios helps identify the pros and cons of each
Features |
Benefits |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Decision Tables Capabilities
Decision Tables are an intuitive approach to creating, testing, and managing business rules that drive business processes. With Decision Tables, business users can leverage a simple, yet powerful table-based approach for managing decisions dynamically.InterstageBusiness Process Manager continues to support the incorporation of business rules both within the process definition as well as through integrations with third-party, commercial rule engines. However, increasingly, enterprises are looking for an alternative that eliminates the need to learn, develop, and support a complex, commercial rule engine infrastructure and yet, provides them with the ability to manage their business logic independent of their process definitions.InterstageBusiness Process Manager’s Decision Tables feature is that option.
Decision Tables provide a process-centric approach to modeling, managing, testing and deploying decision-intensive business activities through an intuitive, web-based graphical interface. It is tightly integrated withInterstageBusiness Process Manager’s process modeling and process execution environment. The Decision Tables feature is not intended to be compared with a stand-alone rules engine; it is designed to co-exist withInterstageBusiness Process Manager.
Why Interstage Business Process Manager’s Decision Tables?
Figure 1: Simple Table Format to Display Business Decisions
|
Key Capabilities |
Benefits |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Enhanced Forms Capabilities
InterstageBusiness Process Manager now supports formatting capabilities in QuickForms including the use of standard style sheets, form templates, and configurable form control properties.
Interstage Business Process Manager has been available since 1998. Over time, we have received various technical queries from customers, evaluators, partners and affiliates regarding the installation, integration, and usage of Interstage Business Process Manager. In this section we cover some of our frequently asked questions. We hope that this will help answer some of the questions you may have to help release your Interstage Business Process Manager-powered application faster.
After changing Interstage Business Process Manager Server Port unable to login to console
Q1. After updating the Interstage Business Process Manager server port number in twf.ini (in v7.1) or ibpm.properties (in v7.4), I was unable to login to Interstage Business Process Manager console. Why?
A1. To change the server port used by the Interstage Business Process Manager server, specify the parameter called RMIPort in twf.ini or ibpm.properties file.
However, this change alone is insufficient. We also need to tell the client application that the server is now listening at a new port number.
Consider the Interstage Business Process Manager console. Change the server port in { Interstage Business Process Manager installation directory}\ibpm\taskmanager\iflowjsp\Taskmanager.conf.
The property to update is:
java.naming.provider.url=rmi://:.
After updating this port number in Taskmanager.conf, restart the Tomcat server or the Interstage Business Process Manager Server altogether.
This should solve the initial login error from the Interstage Business Process Manager console.
User Interface Forms
Q2. Do the user interface forms (data management and work-list) support help files?
Prospects and customers have often asked if UI Forms (for example the JSP’s) can support help files which might be used to provide the user with more information about what is needed to complete the task that the user has.
A2. When one defines an activity and in the activity description one puts a "http://" link, then when that activity is displayed in the console (UI Form), it is turned into a clickable link. If help or other additional information is available for a particular activity, then all you have to do is put the link to that help page in the activity description. This is, of course, a lot less work than actually handling the help. But if you are willing to manage the help files and get them on a web server, then it is easy to link the UI to them.
Below is a screenshot on an activity that has 2 clickable links – http://www.google.com and http://www.msn.com in its description (defined during process definition design).
Timers expiring at wrong time
Q3. Timers based on a calendar, expire at the wrong time. For example, if the business time defined in the calendar is between 08:30 am and 05:00 pm and a timer (business timer to expire after 2 hrs) invocation starts on an activity at 5:30 pm (i.e. timer starts in non-business hours) the timer should expire at 10:30 am, but it expires at 11:00 am.
A3. To correct this issue one needs to specify daylight savings time (DST) in the calendar file. For example the DST entries in the calendar (for US) for year 2006 will be:
2006/04/02=DST(1);
2006/10/29=DST(0);
Based on a given process ID, how can I find out all the activity actors from Model API?
Description
There are at least 3 ways to obtain the activity actor. They are via JavaScript, ServerEnactmentContext and the Interstage Business Process Manager Model API. This article is intended to show you how to obtain an activity actor via Model API calls.
Solution:
Below is a sample program that demonstrates the API calls to make, to obtain the activity actor of a given process ID. There are 2 methods listed below. The second method getActivityHistoryInfo( )formats the information that we are looking for from the Interstage Business Process Manager History table. The activity actor corresponds to the “responsible” field in history table.
The highlighted block of code from method showProcessActors shows how we extract the activity actor value out from the hash table.
Method 1:
private void showProcessActors(String serverName, String serverPort, String userID, String userPassword, String processID) throws Exception {
WFSession session = null;
ProcessInstance pi = null;
try {
session = this.connect(serverName,serverPort,userID,userPassword);
if (session != null)
{
long piID = (new Long(processID)).longValue();
pi = WFObjectFactory.getProcessInstance(piID,session);
if (pi != null)
{ System.out.println("--------------------------------------");
dLog.prn(1,"Process ID: " + piID + " retrieved!");
NodeInstance[] nis = pi.getMemberNodeInstances();
Vector v = new Vector();
// I cant believe there is no built in operation to copy an array into a vector!
int last = nis.length;
for (int i=0; i
v.addElement(nis[i]);
}
for (int i=0; i
NodeInstance ni = (NodeInstance) v.elementAt(i);
int state = ni.getState();
long nodeId = ni.getNodeInstanceId();
String completedDate = "";
if (state == NodeInstance.STATE_COMPLETED) {
completedDate = "unknown";
}
if (state == NodeInstance.STATE_COMPLETED) {
long compDate = -1;
Hashtable historyInfoTable = this.getActivityHistoryInfo(pi,ni.getNodeInstanceId());
Long completionDateLong = (Long) historyInfoTable.get("CompletionDate");
if(completionDateLong!=null){
compDate = completionDateLong.longValue();
}
String responsibleStr = (String) historyInfoTable.get("Responsible");
if(responsibleStr==null) {
responsibleStr = "";
}