TIBCO Business Studio? Getting Started Best Practices

Table of Contents

• Process Modelling
• BPM & BPMN Patterns
• Working with TIBCO Business Studio
• Teamwork
• Projects
• Project Organization
• Multiple Studio Projects
• Naming Conventions
• Project Versioning
• Business Object Model
• Global Data
• Process Development
• Process Activities
• Subprocedures
• Conditions
• Forms
• Pageflows
• Custom Form Controls
• Organizational Models
• Service Integration
• Eclipse Auto Build Mode
• Summary

Process Modelling

Here are some Getting Started Hints on working with TIBCO Business Studio? for TIBCO^® BPM Enterprise

BPM & BPMN Patterns

• Create your first Case data project in 10 minutes with TIBCO® BPM
• Sample of storing BPM configurations in Global Data
• Modeling a Service Process
• The new Data Mapper Activity
• Business Process Management Glossary
• BPMe 5.x Samples on GitHub

Working with TIBCO Business Studio

Teamwork

Make use of Tools like the Business Asset Manager (SVN) delivered with TIBCO Business Studio. This gives you the ability to work in a Team (check-in/-out)

Projects

Close un-used projects, to speed up development experience.

Don?t use spaces in Project Names or Package Names.

Project Organization

It's a good best practice to create multiple Projects of reusable components/subprocedures:

• any Main Business Procedure should have his own TIBCO Business Studio Project
• every Bundle of reusable subprocedure or page flows should have its own TIBCO Business Studio Project
• i.e. for technical Subprocedures, one TIBCO Business Studio Project for every back end.
• Business Objects should be stored in a separated TIBCO Business Studio Project
• Organization Models should be stored in a separated TIBCO Business Studio Project
• Also, think about separation with multiple XPDL in multiple TIBCO Business Studio Projects

This is mainly because of reusability and separation of development & deployments, i.e. for the TIBCO BPM Destination, every TIBCO Business Studio Project is built into a discreet deployment archive.

Example of a Project Structure, here ...

Multiple Studio Projects

Use separate Studio projects for Data, Org, Processes. Structure your project as follows:

• 1- Project per Business Object Model Group (typically the parent data model, and direct child elements that are not reused by other BOMS) for 1 to many processes
• Why? So that you can redeploy changes without having to retest the entire solution (just test the specific model and associated processes/forms)
• 1- Project with Organizational Model for 1 to many processes
• n- projects with common sub-processes and process interfaces
• n- Projects with reusable Sub-process Interfaces, and keep them separate from Main & Sub procedures (depended on use case)
• n- Projects with processes, one XPDL per process

Use separate BOM to define services messages, i.e. for request/response, in case you need special Classes here, and you can't directly reuse the TIBCO BPM Data Model.

Use the Reusable Subprocess Interfaces Pattern only for procedures that maybe change in the future e.g. business Procedures, to avoid dependencies.

E.g. Technical Procedures, like loading BPM Configuration Data, should not use the Reuseable Subprocess Interfaces Pattern as they never will change.

• more details about Project Segmentation and Separation
• Working with the Dependency Viewer

Naming Conventions

Set and apply a naming convention for each TIBCO BPM project artifact. Enrich further it if needed by a specific project. The naming convention will help you to name project artifacts based on project context (business domain, application, process).  

Suggested naming conventions for Process Level, and use Project Naming ending for the Type to Artifact, i.e.

• *.org - for Org Models
• *.bom - for Business Object Models
• *.gdata - for Global Data Object Models
• *.wsdl - for Service WSDL
• *.proc - for main procedure packages
• *.sub - for sub procedure packages
• *.pflow - for page flow packages
• *.pi - for Process Interfaces
• *.comp - for Form Component Projects
• *.soa - for AMX SOA Projects and AMX Mediation Projects
• ?global.fac? - as there is only one Facade Project per Server Environment, the Project should have a Global name.

e.g. Class Names, Attributes, Fields, and Package Names are up to the customer, and/or the Products come with some default suggestions.

Project Versioning

Using a common project versioning scheme is important when communicating the types of changes that occur within a project during its lifecycle. This allows for other project teams, project managers, and also platform support to quickly determine the impacts of change during upgrade/deployment cycles.

The best practice is to use three discrete version numbers in the form [major.minor.micro.x], where:

• Major - a revision change that breaks API, and has no backward compatibility, typically containing new features, or removal of old/deprecated features.
• Minor - an upgrade (with new methods or features), but with full backward compatibility.
• Micro - a revision containing fixes and enhancements, with no functional changes.

Best practices are to ensure that the project version is correctly updated/revisioned (major.minor.micro.x), and the XPDL package version is revisioned equivalently. Process templates rely purely on the Process Package, which in-turn relies on Project Version # (you would notice XPDL package version complains if it goes out of synch from the Project version #).

For a successful build, typically the project versions = .xpdl package version = Deployable Archive = process template version.

When upgrading a project containing active instances for a current version of a process:

• The application will get upgraded to the new version (new app template/version deployed to the TIBCO BPM node, while old app remains active).
• Any new instances will be created using the new process template
• The old version of the app will go into a "Prepared for Undeployed state, not able to do any more work" (meaning no more new work)
• The active instances will continue to run on the old version of the process template and old process templates will remain in the "Process Views" until the active instances get completed.

Once the old instances get completed, the old version of the app will be undeployed from the respective TIBCO BPM node.

Business Object Model

Model for UI effectiveness and not for object-oriented beauty. Use the Business Object Model (BOM) to create small Form UI Components, not as a full structure complex Data Model. This helps later to build small Form Components & Pageflows and gives the ability to create good Business Usecase focused Services to Backends. Use separate BOM to define services messages, i.e. for request/response, in case you need special Classes here, and you can't directly reuse the BPM Data Model.

Global Data

Use persisted Business Data to share Data between multiple Case-Instance, and follow the rules below:

• Define Global Data to support Model-Driven Forms
• Create Embeddable Form Components for Global Data Classes
• Define Global Data Searchable Fields as needed: a DB-Index is created for every search field.
• use Pageflows for BPM Tasks, to read Data as Reference: Data gets automatically written back to the Store, short time between read&write.
• Use Global Data only for BPM relevant Data, or Search Data. 

The following are critical in the context of long-living Business Data Objects:

• Destructive changes should not be made, post-deployment:
  • Do not change field names
  • Do not change field types
• Don?t store a Global Data Reference for a long period of Time in a BPM process instance. Background: In case data is updated, only readers afterward can update Data.
• Avoid Global Data usage if it duplicates Backend Enterprise Data, rather use service to invoke the Backend and retrieve the data.

Process Development

Start all times with the "Happy Flow" or known as "Green Path". Use colors and shape size to identity a happy path and type of tasks. Think about what should be later executed in persistent BPM Engine, and what is later only a Composite of some Request/Reply Services.

Process Activities

Specify the interface for each activity, this speed-up development and defines a clear interface architecture.

Subprocedures

Use process interface for subprocesses that will probably change in the future many times or could dynamically change. This is also helpful to avoid Migration Problems at Runtime.

Conditions

Give a Name to every Process Condition, this helps later to understand the Process better,

i.e. if you look at it one year later, and it is helpful for BPM Destination Process Instance Migration Points, too.

Forms

Use Embedded Form Components, this makes parts of Forms reusable. For data validation use event-driven validation rules, instead of long "submit" Scripts. This speed-up Form execution and development. Use CSS to customize the form's appearance. Put reusable scripts/functions in external javascript resource files. It is recommended to follow these rules in the current BPM version, during BOM design and Form Design:

• Use BOM as a kind of ?View Object Model (VOM)?, only
• create only relationships, that are used in all Forms
• create only mandatory fields, that are mandatory in all Forms
• Required fields/attributes must be ?globally required?
• Required fields on the Form must be enabled/disabled by custom scripts
• Visibility of fields must be enabled/disabled by custom scripts
• Use ?property bindings?, instead of on long-form initial Scripts
• avoid Loops in Javascript on the Client Side as they run in the Browser

By following these during BOM design, helps later to define nice Forms easily

Pageflows

Consider in Pageflow Wizard implementations that they run in front of the Human User,

so they should respond quickly, here are some basic rules

• pre-load Data before the Workitem get scheduled
• avoid long Backend Service load times
• prepare Data as needed by the Forms by Server-side Services, instead of doing large data transformations on the Pagflow Server-Side or Client-Side using Javascript

This again is to make the Pageflow Definition business-friendly, and not a technical implementation.

Custom Form Controls

Use custom Form Controls there you need special functionality, or lots of java scripting in Forms, to increase simplified usage & re-usability. 

Organizational Models

Use the Organizational Model as some kind of Meta-Orgmodel for one or more Business Procedures.

It doesn't need to show the whole Organization in One. i.e. for the BPM Destination, you can deploy multiple Organizational Models to one Environment.

Service Integration

Use a Composite Service Layer to define services used by the BPM. This helps to avoid:

• a lot of technical Implementations,
• inside Business-driven & focused BPM Solution.
• Use a Service Layer here instead.

Create WSDL's from BOM's, this enables a Model-Driven development.

Do not handle technical Service Timeouts, using a Timer on the Service-Task boundary. Better set this Timer at Service Connection Level, i.e. for the BPM Destination inside a HTTP Client Resource Template.

Create a reusable sub-process for generic service task error handling.

Eclipse Auto Build Mode

Leave the Auto Build Mode enabled at all times. This is needed because this build generates content & mapping basics, too.

Summary

This all allows later a better...

• Traceability - understand deployed elements and trace immediately with Studio Project artifact.
• Development speed - logically find the information and links. The speed learning curve for newcomers in a project.
• Quality - find suspicious/false reuse (name not matching the context), simplify project audit.

Back to Main TIBCO® BPM - Modeling Wiki page 

Attachments

activematrix-bpm-guidelines_2016.pdf

bestpractices_for_delivering_bpm_projects.pdf

process_modeling-12_best_practices.pdf

tucon_2013_process_patterns.pdf