Just like developing a solution in any programming language, while designing and developing integration solutions using TIBCO Designer, it is always recommended to follow best practices defined in general or any best practices formulated in your own organization to ensure that all project artifacts are rightly designed, developed, organized and assembled. Following the best practices helps a lot in team collaboration, code re-use, future enhancements, peer reviews, knowledge transfer and in all phases of software development life cycle.
In this TIBCO BW Designer Project Best Practices article, I will share some of the best practices that can be helpful for any TIBCO BW developer. Please be aware that these are the best practices as per my experience only and it may vary depending on your business scenarios and your organizational preferences.
Proper Categorization of resources and Well defined folder structure
Any TIBCO designer project comprises of dozens of resources of different types including processes, schemas, WSDLs, archives, connections etc. Following best practices should be followed to organize your project:
Processes Categorization and Organization in BW Designer Project:
Separate folders should be created for Processes. with further classification as sub-folders for Processes based on business area or the associated parties. It might be your organizational preference if you want to classify your processes based on business area or parties. For example, you might opt for placing all processes related to Inventory in one folder or you might go with party based approach where you will place all processes specific to PartyX in one folder.
Another best practice that you can follow for processes in your designer project is to follow the hierarchy rules. Using this approach, place your processes in different layers like Inbound, Internal, Outbound depending on process interfacing. Any processes which are common by nature should also be placed separately so that they may be re-used when and where required. You may even opt to create a library using Library builder for such re-usable resources and import them in any project when needed.
Shared Resources Categorization and Organization in BW Designer Project:
Any project in TIBCO Designer usually involves a number of shared resources including JDBC Connections, HTTP Connections, Schemas, WSDLS etc. which are normally huge in number and should be properly organized to avoid any mess in the project.
All Connections should be placed in a separate folder with additional sub-folders for each type of connections e.g. one folder for Database Connections, one for HTTP Connections and so on.
XSD Schemas should be categorized in folders as per business area or party depending on your organizational preferences. It is recommended to follow the same preference for XSD Schemas as you follow for the processes.
WSDLS, client certificates and any other shared resources should also be placed in well-defined folders with meaningful names.
Naming Conventions and Best Practices
Just like any other programming language, naming should be given a thorough consideration while defining any artifacts in TIBCO designer projects. Names of all processes, schemas, WSDLs etc. should be meaningful and should clearly indicate their purpose. Following are some conventions that you can follow for naming your resources:
* Process names should be Verb+Object. E.g. a process which receives inventory data can be named as ReceiveInventoryData. You don’t need to mention from whom it received the data as that will be clear from the folder name if you followed party based folder structuring convention. However, if you used business area based classification, you may opt for adding party name in the process name for more clarity.
* XML Schemas should also be named with meaningful words. You should name schemas as noun depending on the object type. For example, a schema which is used by order processing, could be named as OrderSchema. For schemas, follow proper conventions for namespaces as well and all your schemas should follow the same convention for namespaces to avoid any namespace conflicts. e.g. you can opt for the following convention for the namespaces:
http://<<your_org_url>>/<<business_araa>>/<<schema_version>>
* All connections resources should be named by explicitly mentioning the system or the party for which the connection is meant for. E.g. a database connection which will be used to connect to SQL production database should be named as JDBC_SQL_PROD_Connection. Underscore (_) can be replaced with dash (-) as per your own preferences. Similarly, a HTTPs connection for Party ABC can be named as HTTPS_ABC_Connection.
* WSDLS or WADL files should be named as per party name and business area. E.g. a WSDL for Party ABC for Order related service should be named as ABC_ORDER_WSDL. However, if you have already created folder categorization based on party or business area, you can make necessary modifications to the convention accordingly.
Global Variables Best Practices
Global variables are used in any BW project to allow deployment time changes for any configurable values without re-packaging the entire project. While developing a BW project, you should always think of any such elements which may need an update at deployment time at any later stage and pull out such elements and place them as global.
All connection parameters (e.g. host IP, Port, JDBC connection strings, usernames, passwords etc.) and any other configurable variables should be properly categorized when adding them as global variable. A proper grouping of GVs can help your operations team to easily and quickly locate the GV of their interest. E.g. all Connections GVs should be grouped as a Variable Group and then further sub-grouping should be done for GVs related to HTTP, JDBC, JMS connections etc.
Also, don’t forget to check service checkbox for any GVs which you want to make configurable at service level (PAR level).
This completes some basic level of best practices that can help you a lot for better project structuring. This is not an exhaustive list and may not be covering many areas as TIBCO BW is very rich product with tons of features and It is not possible to shed a light from all angles in a single post. For some additional help, you can refer to one of my previous posts TIBCO BW Development 10 best practices and I hope that will also be helpful for you.
You are welcomed to comment below if you have anything to say further on this.
