This article is to explain how to access both Module property values and Java property values in a BusinessWorks mapping. Module properties There are two kinds of module properties some are defined by the application developer and some are predefined in BusinessWorks. The module properties defined by the application developer are managed in the ‘User’ tab of the Module Properties: The predefined module properties are visible in the ‘System’ tab of the Module Properties: The value of a given module property can be accessed in a mapping using the following XPATH function: bw:getModuleProperty() For example to access a property called ‘MyProperty’ that is part of a group called ‘Service’ you have to use the following XPATH formula: bw:getModuleProperty(“/Service/MyProperty”) Similarly, this function can also be used to access the predefined properties. For example, to access the property ‘BW.APPNODE.NAME’, that contains the name of the appnode hosting the application, have to use the following XPATH formula: bw:getModuleProperty(“BW.APPNODE.NAME”) Note that the deployment unit name and version are the name and version of the running application. It is also possible to access properties defined in Shared Modules using the following syntax: bw:getModuleProperty(“//<Shared Module Name>///<GroupName>/<PropertyName>”) For example to access the value of the property “MsgLabel” part of the “SMProperties“ group of the “MySharedModule” Shared Module you have to use the following syntax: bw:getModuleProperty(“//MySharedModule///SMProperties/MsgLabel”) In case there are multiple group levels the name of each sub-level should be included like this: bw:getModuleProperty(“//<Shared Module Name>///<GroupNameLevel1>/<GroupNameLevel2>/<GroupNameLevelN>/<PropertyName>”) For more details you may refer to the following KB article: https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-46830 Note that starting from BusinessWorks 6.10 it is possible to directly use Module Properties in Mappings (with the limitation that in case the name of a property would change the developer would have to update the impacted mappings manually). Module Properties are available in the DataSource tab of the Mapper, you can select a property and drag and drop it in the target field, this automatically creates an XPATH formula using the getModuleProperty() function to access the property value. System properties System properties are in fact the Java properties defined by default in Java or defined in the appnode tra file or config.ini file. The value of a given system property can be accessed in a mapping using the following XPATH function: bw:getSystemProperty() The values of the following java system properties are accessible using this approach: file.encoding java.version user.home os.name For example to access the Java property ‘java.version’ you have to use the following XPATH formula: bw:getSystemProperty(“java.version”) The values of the properties defined in an appnode tra file or config.ini file, can also be accessed using this function but for some properties it is only working in deployed mode. For example to access the appnode Java property ‘logback.configurationFile’ you have to use the following XPATH formula: bw:getSystemProperty(“logback.configurationFile”) Additional elements A sample project is attached. AccessSystemProperties.zip

Updating an XSD schema namespace in a BusinessWorks application or shared module have a significant impact for the processes using it while all the activities using the updated schema are impacted. Even if not explicitly mentioned in the documentation, it is possible in BusinessWorks Studio to update an XSD schema namespace and to update automatically all the impacted processes. This can be done with the following: . Right click on the target xsd file . Select ‘Refactor -> Rename XSD schema namespace’ . Update the name space as needed and make sure the option ‘Update references to the XSD schema namespace’ is checked Once done you can check that all activities in all processes using the schema have been updated. If the XSD schema is in a shared module the update is made in all applications referring to the shared module that are opened in the current workspace.

It is quiet common for BusinessWorks developers to encounter difficulties in understanding when Module Shared Variables can be accessed directly and when it is necessary to use a Critical Section. This article goal is to bring needed clarifications on this topic. Module Shared Variables can be shared between multiple processes definitions and multiple process instances. Because of the multi-threaded nature of the BusinessWorks engine there are some cases where it is necessary to use Critical Sections. One important thing to know is that accesses to a given Module Shared Variable, using the ‘Get Shared Variable’ and ‘Set Shared Variable’ activities, are synchronized. Reading or setting the value of a Module Shared Variable This means that for just reading the current value of a Module Shared Variable, at the moment of the Process execution, it is possible to just use the ‘Get Shared Variable’ activity without using a Critical Section. This means also that for just setting the value of a Module Shared Variable without taking care of its current value it is possible to just use the ‘Set Shared Variable’ without using a Critical Section. Updating the value of a Module Shared Variable in a process In the case of a process that needs to read the current value of a Module Shared Variable and update it, for example to increase a counter or update some king of semaphore flag, it is necessary to use a critical section while multiple instances of this Process might be executing and accessing the variable at the same time. In such case the ‘Get Shared Variable’ and ‘Set Shared Variable’ activities must be included in a Critical Section. Updating the value of a Module Shared Variable in different processes It is also possible for different process definitions to update the same Module Shared Variable using a different logic. In that case it is necessary to use a Critical Section in each of the process definitions and to synchronize them using the Module Shared Variable. This can be done by checking the ‘Shared Lock’ option and selecting a Module Shared Variable. The selected Module Shared Variable is then used as a semaphore to control execution of the different Critical Sections referring to it. Using a Module Shared Variable as a Semaphore The approach to use multiple critical sections synchronized with a Module Shared Variable can also be used to manage accesses to external resources like for example a file, in such case a Critical Section with a Shared Lock can be used to manage concurrent accesses to the target file from different processes of an application. Accesses to Job Shared Variables Job Shared Variables are local to a process instance and there is no need to use Critical Sections to access them except in case where the same Job Shared Variable would be updated in parallel branches of a process definition. Additional elements A sample project is attached to this article. Elements for BusinessWorks 5.X The elements provided in this article also applies to BusinessWorks 5.X except that the ‘Shared Lock’ mechanism is not available in BusinessWorks 5.X. Reference elements https://docs.tibco.com/pub/activematrix_businessworks/6.10.0/doc/html/Default.htm#app-dev-guide/working-with-critica.htm https://docs.tibco.com/pub/activematrix_businessworks/6.10.0/doc/html/Default.htm#binding-palette/critical-section.htm SharedVariableAccess.zip

While I sometimes receive the question to know how to get started on BusinessWorks or BusinessWorks Container Edition I thought this would be useful to write an article listing resources freely available on line and giving directions for people willing to discover and learn by themselves. My recommendation is to take the following approach: . Read the product documentations introducing BusinessWorks concepts and architecture for both design time and run time . Download the product, install it in a sand box environment and try it . Check the samples provided with the product . Read some blog articles I would also recommend to consider using TIBCO Education training services, there are two options available: . On line training . Instructor lead training More details are available here: https://www.tibco.com/education Documentations to read BusinessWorks and BusinessWorks Container Edition documentations are freely available at the following URL: https://docs.tibco.com/products/tibco-activematrix-businessworks For BusinessWorks, I recommend reading the following documents in the order they appear below: . ‘Getting started’ . ‘Concepts’, that gives an introduction of what is BusinessWorks and how it is working . ‘Application Development’, that gives an introduction on developing with BusinessWorks and provide details on important design time concepts . ‘Administration’, that present the BusinessWorks run time architecture and provide details on how to configure the BusinessWorks run time components (you can focus on the introduction part of each chapter and keep the details for later) If you are interested by the solutions available to migrate BusinessWorks 5.X applications to BusinessWorks 6.X you may also have a look to the ‘Migration’ document. The other documents should be used as references when you need detailed elements on something, at this stage you can just have a quick look to familiarize on their content. In the ‘Binding and Palettes References’ document you have details on each activity or Shared Resource, in the ‘REST reference’ document you have all details about REST Bindings and etc… For BusinessWorks Container Edition, I recommend reading the following documents in the order they appear below: . ‘Getting started’ . ‘Concepts’, that gives an introduction of what is BusinessWorks and how it is working . ‘Application Development’, that gives an introduction on developing with BusinessWorks and provide details on important design time concepts . the ‘Application Development for Docker’ section of the ‘Application Development’ documentation. https://docs.tibco.com/pub/bwce/2.9.1/doc/html/Default.htm#app-dev-guide/application-developm3.htm Downloading BusinessWorks Download BusinessWorks using your company account on the TIBCO edelivery site: https://edelivery.tibco.com If you are on your own it is possible to download BusinessWorks and BusinessWorks Container Edition from the TIBCO Access Point page: https://tap.tibco.com/storefront/index.ep Note that you will need to register and the versions available from this site are not recent. Once registered you can login and download BusinessWorks. Once downloaded you can install BusinessWorks following the ‘Installation’ document available on the page mentioned before. Looking at samples provided with BusinessWorks Once installed you can launch Studio and start creating an application with a few processes. After creating a first workspace a page with links to sample applications is displayed, you can have a look to some of them. BusinessWorks and BusinessWorks Container Edition general samples are available in the following directory: <TIBCO_HOME>/bw/6.10/samples/AppSpace BusinessWorks Container Edition specific samples are available in the following directory: <TIBCO_HOME>/bw/6.10/samples/Container Going further After reading the documentation, installing BusinessWorks and looking at the samples you can go further by looking at other articles on TIBCO Community or on Internet blogs.

Since the early days of BusinessWorks 6.X, applications using resources that cannot be properly initialized are considered to be impaired and cannot start. Generally, this is because one of the Shared Resources used by an application cannot start without error, this can be for example a JMS connection resource that cannot connect to the target EMS server because it is unavailable, or an HTTP Connector resource that cannot initialize because the port it is using is already opened by another application. This behavior allows to make sure an application start only in a consistent state but in some cases, it is useful to start an application even if some of its Components or Process Starters are not available (for debugging purpose or to allow running an application in a production environment even if some part of it are not active). Since BusinessWorks 6.9.1 a property has been introduced to force an application to start even if it is impaired. The property name is: bw.independent.component.startup To enable applications to start even if they are impaired you then have to do the following: . Go to the target appnode directory: <TIBCO_HOME>/bw/6.X/domains/<DOMAIN_NAME>/appnodes/<APPSPACE_NAME>/<APPNODE_NAME> . Edit the config.ini file to add the property and set it to true: bw.independent.component.startup=true . restart the appnode Useful things to know I tested this with a JMS Receive Message Process Starter and it is working fine: . If the EMS server is down while the application is started the corresponding Components (or Process Starters) are disabled, and you can see this in the TEA or using the bwagent REST API: . Then once the EMS server is restarted you can re-enable the JMS components in the TEA or using the bwagent REST API : . And check the Component is now enabled: I also tested with a Rendezvous Subscriber Process Starter and a Receive Email Process Starter and it is working fine. I didn’t found a way to get an application to be in an Impaired state because of a problem with a File Poller Process Starter or a TCP Receiver Process Starter. Limitations I also tested this with a REST Binding Component using an HTTP Connector resource and unfortunately it is not working with both BusinessWorks 6.9.1 and BusinessWorks 6.10. I got also the same behavior for HTTP Receive Process starters. I reported this to TIBCO support. Reference elements Extract from the TIBCO Documentation: TIBCO support knowledge base article on Impaired applications: https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-41342 Additional elements You can also have a look to this article from my colleague Alexandre Vasquez: https://medium.com/coderbyte/tibfaqs-how-to-solve-an-impaired-status-on-your-businessworks-application-326c23a3f624

It is sometimes needed to do things before starting to process events in an application, like for example loading values from files or databases in Shared Variables, or checking the availability of resources that are critical for the application. It is also sometimes needed to do things when an application is shutting down, like for example cleaning temporary files in a working directory or sending a JMS message to notify a monitoring solution. This can be done in BusinessWorks and BusinessWorks Container Edition by using an Activator Process, such Process can be created with the following: . Go to the Module Descriptor Overview panel of your application and click on the Create Activator Process button . The Activator Process Creation panel is displayed, selected the target Process Folder and Package, then enter a name for the Process and click Finish . The Activator Process is now created . Now you can implement your Activator Process as you need You can have only one Activator Process per application. This is generally a good practice to limit the number of activities in an Activator Process and to use Sub Processes if different things have to be done. In the case you would not need to do something at Startup and nothing at Shutdown you can just leave empty the onShutdown branch (and vice versa).

One challenge while handling files in BusinessWorks is that we generally don’t have control on the actual file sizes and this sometimes require to use large amounts of memory and may even create situations where ‘Out of Memory’ errors occurs. An interesting feature introduced in BusinessWorks 6.9.1 is the capability to send or receive a file using HTTP Send and HTTP Receive activities without having to load the whole file content in memory. With this new feature files are sent or received in chunks of a limited size and directly read from disk or wrote to disk. Such approach is sometimes referred to has file streaming. This blog article is to explain how to use this new feature. Sending a file over HTTP The ‘Send HTTP Request’ activity has to be configured with the following: . In the General tab, select an available HTTP Client resource, or createn a new one, and set the Post Data Type configuration option to ‘File’ . In the Input tab — Set the ‘Method’ field to “POST” — Set the ‘FilePath’ field to the full path of the file to be sent — Set the ‘Time out’ field to an Integer value (in milli seconds — for example 60 000 for a minute) — Set the ‘Dynamic Headers’ -> ‘Header’ -> ‘Name’ to “Content-Disposition” — Set the ‘Dynamic Headers’ -> ‘Header’ -> ‘Value’ to “attachment; filename=<file name at reception>” (for example ClientFile.txt) Receiving a file over HTTP The ‘Receive HTTP’ activity has to be configured with the following: . In the General tab, select an available HTTP Connection resource, or create a new one, and set the Output Style configuration option to ‘File’ . In the Advanced tab : — Check the ‘Write to File’ option — Set the Buffer Size to an integer value (in bytes — the default value is 1024) — Set the Directory to the name of the directory where received files are written — Optionally you can set the ‘Threshold Data’ option to a value (in bytes), when the value is zero files are always written to the defined target directory, when the value is greater than zero received files are written to disk only if they are greater than this value . Don’t forget to include a ‘Send HTTP Response’ activity after the ‘Receive HTTP’ activity

During performance or volume tests, or while working in the analysis of a complex issue, it is sometimes useful to view what is going on within an Appnode JVM to be able to identify bottlenecks and improve the Appnode or the BusinessWorks applications runtime configuration. This is also useful to compare the behavior of different Garbage Collectors or to evaluate different Garbage Collector configurations. This article is to explain how to monitor a BusinessWorks Appnode using JMX and the open source solution JVisualVM. Configure the appnode to enable JMX This can be done with the following: . Go to the target appnode ‘bin’ directory, this is in the following form: <TIBCO_HOME>/bw/6.X/domain/<DOMAIN_NAME>/appnodes/<APPSPACE_NAME>/<APPNODE_NAME>/bin . Edit the .tra file of the appnode . At the end of the file add the following lines java.property.com.sun.management.jmxremote=true java.property.com.sun.management.jmxremote.port=9614 java.property.com.sun.management.jmxremote.local.only=false java.property.com.sun.management.jmxremote.authenticate=false java.property.com.sun.management.jmxremote.ssl=false . Restart the appnode Note : if you need to monitor multiple appnodes you have to use a unique port number of each appnode Install JVIsualVM JVisualVM is an open source solution, it can be downloaded at the following URL: https://visualvm.github.io/download.html To install it you just have to unzip the downloaded package in the directory of your choice. JVisualVM needs a Java JDK 8 at minimum to run, if you don’t have a Java JDK 8 available in your environment you have install one (you can use OpenJDK 8 for example). If your JDK installation is included in your environment path you can use JVisualVM directly otherwise you have to update the default JVisualVM configuration: . Go in the JVisualVM configuration directory <JVISUALVM_HOME>/etc . Edit the file jvisualvm.conf . Uncomment the following line and add the path to your JDK change #visualvm_jdkhome=”/path/to/jdk” to visualvm_jdkhome=c:\tools\OJDK8 Monitor the appnode with JVisualVM Once JVisualVM is launched use the “File -> Open JMX connection” menu option, the following dialog open: Enter your target appnode hostname and JMX port and click OK: The target appnode now appears in the application tab: Right click on it and select ‘Connect’, then right click again and select ‘Open’, the Overview tab is showing up: You can select the Monitor tab to monitor the CPU usage, Heap size and usage, and Classes and threads related statistics: You can select the Threads tab to view Threads that are used by the Appnode: Finally you can use the ‘Heap Dump’ button to generate a ‘Heap Dump’ for further analysis: Additional elements for a memory leak analysis In the context of a memory leak analysis you can the use Eclipse Memory Analyser to check a Thread Dump generated by JVisualVM. This tool, from the Eclipse Fundation, can be downloaded at the following URL: https://projects.eclipse.org/projects/tools.mat/downloads Additional elements for BusinessWorks 5.X The same approach can be used with a BusinessWorks 5.X engine. You just have to update the .tra file of the target application to add the properties mentioned above. The .tra file of an application is located in the following directory: <DOMAIN_HOME>/application/<APPLICATION_NAME>

In BusinessWorks 6.X it is possible to deploy multiple applications in an appspace and then to have at run time multiple applications running in the same appnode. In the default configuration all the running applications log messages are going to the appnode log file ‘bwappnode.log’ located in the target appnode log directory (<TIBCO_HOME>/bw/6.X/domains/<DOMAIN_NAME>/appnodes/<APPSPACE_NAME>/<APPNODE_NAME>/log). In order to ease application trouble shooting it is possible in recent BusinessWorks releases, precisely since BusinessWorks 6.6.0, to have a separate log file for each application. This article is to explain how to set-up such configuration and the limitations to be considered. How to configure an appnode to have separate log files per application This can be done with the following: . Go to the target appnode directory <TIBCO_HOME>/bw/6.X/domains/<DOMAIN_NAME>/appnodes/<APPSPACE_NAME>/<APPNODE_NAME> . Edit the config.ini file to add the following property: bw.engine.separate.logs.by.app=true . Edit the logback.xml file to add the following tag in the root logger definition: <appender-ref ref=”APPLICATION-FILE”/> . Restart the appnode With this configuration application logfiles are written next to the bwappnode.log file in the target appnode log directory. The application log file names are in the form <application_name>.application.log. It is possible to add some loggers configured with the DEBUG level in the configuration above by including the following tag in their definition: <appender-ref ref=”APPLICATION-FILE”/> For example it is possible to add the DEBUG trace of the REST/JSON palette in the application log file using the following logger definition: It is also possible to control log messages destination at logger level, you can refer to the BusinessWorks documentation for more details. Limitations to be considered . Application start and stop messages (Starting, Started, Stopping, Stopped,...) remain in the appnode log file . Third party loggers, like for example the apache and jetty loggers, do not support logging in separate application log files. The related log messages remain in the appnode log file . When multiple versions of the same application are deployed in the same appspace the logs of the different versions of the application are going to the same file Since BusinessWorks 6.10 it is possible to have the full application version (major.minor.patch) included in the log by adding the following property in the appnode config.ini file: bw.frwk.version.format=true Reference elements BusinessWorks documentation: https://docs.tibco.com/pub/activematrix_businessworks/6.10.0/doc/html/Default.htm#administration/application-logging.htm Article explaining how to configure logging at activity level: https://community.tibco.com/articles/tibco-activematrix-businessworks/bw6x-bwce-how-to-enable-activity-level-logging-in-businessworks-6x-and-businessworks-container-edition-r3383/

While this is common in integration projects to have to manage the same integration scenario for different business objects this translate in having to implement the same flow multiple times but with different Schemas and Mappings in BusinessWorks. To help manage such requirements recent BusinessWorks versions support creating a template from a project and creating a new project using such template. This new blog article is to explain how to use this feature. Creation of a template Create an application skeleton in Studio having in mind this will become a template used to create a number of actual applications. For example you can create a template of an application processing JMS messages that would includes . A JMS connection resource . The properties needed to configure such resource . A process with a JMS Receive Message activity, logging activities, a call to a sub-process containing the business logic to implement in each variant and a default error handler Once your template application is created, you can create a template with the following: . Right click on the application you want to use to create a Template . Select Export -> Studio Projects as Template A panel similar to the example below appears: . Click on Select Dependencies and select a target folder to manage the templates . Click Next, , a panel similar to the example below appears Update the proposed Name and Version and add a Description as needed. . Click Finish . After 10 to 20 seconds you can check the template as been created in the specified template folder Note that a template file is in zip format and can be unzipped if needed. Creation of an application from a template You can create a new BusinessWorks project from a template with the following: . Right click in the Project Explorer area . Then select the menu New -> BusinessWorks Project from Template In the panel that appears, select the template project you want to use: . Click Next, a panel similar to the example below appears . Click Next , a panel similar to the example below appears You can update the Application Name and Module Name by selecting the existing name in the column on the left and entering the new name in the column on the right. . Click Finish You now have to add the elements needed to fully implement the new application instance, this would include the schema describing the message received over JMS, the resource describing the back-end service that need to be called and the sub process doing the needed mappings and calling the back-end. Reference elements BusinessWorks documentation https://docs.tibco.com/pub/activematrix_businessworks/6.10.0/doc/html/Default.htm#app-dev-guide/exporting-a-project-.htm?Highlight=Template https://docs.tibco.com/pub/activematrix_businessworks/6.10.0/doc/html/Default.htm#app-dev-guide/creating-a-project-f.htm?Highlight=Template

An interesting feature introduced by Hawk 6.X is the capability to invoke available Hawk methods using a generic REST API. In a BusinessWorks context this allows to easily collect KPI’s available in Hawk and integrate them into custom dashboards or reports. Note that you need to have a valid Hawk licence to be able to use the Hawk component exposing the REST API in both BusinessWorks 6.X and BusinessWorks 5.X environments. For BusinessWorks 5.X you have to use BusinessWorks 5.15 or higher while previous releases are not using the Hawk 6.X version. This new article explains how to use the Hawk REST API to invoke methods exposed by both the BusinessWorks 6.X and BusinessWorks 5.X microagents. Architecture The Hawk REST API is exposed by a new component introduced in Hawk 6.X that is the Hawk Console. To be able to use the Hawk REST API an instance of this component should be running on one of the server of the configuration. When a method of the Hawk REST API is called the Hawk Console forward the call to the target Hawk Agent that itself send it to the target micro-agent, once the micro-agent replies the Hawk Agent forward the reply to the Hawk Console that finally put it in a generic JSON format and returns it to the caller. Prerequisites to use the Hawk REST API You need to make sure there is an Hawk Console running in your target environment and you have the following elements: . The hostname and port to use to access the Hawk Console . A username and password allowing to connect to the Hawk Console By default the Hawk Console is available on the following URL: http://<host>:8083/HawkConsole For example: http://server1:8083/HawkConsole By default you can connect with the usual admin/admin. The Hawk Console should also be configured to access the target Hawk domain. If needed this can be done with the following: . Click the “+’ button on the right of the page (in the middle) . Enter the details for your target domain All details of the target Hawk domain have to be entered, you may need to scroll to see all parameters. . Click ‘Configure’ once all details have been entered. Checking the Hawk REST API The Hawk Console is managing a page in Swagger UI format where can be found the list of available Hawk REST API methods and details on the methods. It also possible to test the methods on line. By default this page is available on the following URL: http://<host>:8083/HawkConsole/v1/docs For example: http://server1:8083/HawkConsole/v1/docs The available REST methods are available in Swagger UI format: Calling the Hawk REST API — Getting needed details on the target domain This is generally useful to call the GET {domain}/agent API to get details about the target domain. This can be done from the Swagger UI page: . First select the GET /{domain}/agent method . Enter the name of the target domain (‘default’ in the example below) . Click ‘Try it Out’ Enter the username / password that you have to connect to the HawkConsole. . Check the output In the output we can see the value of the ‘dns’ parameter that is useful to do further calls. Calling the Hawk REST API — Listing available micro-agents for a given Hawk Agent . This can be done with the following method GET /{domain}/{dns}/{agent}/Microagent We have to use the domain, dns and agent name we got from the previous call. . Click ‘Try it Out’ . Check the target appnode Hawk micro-agent is present in the output For example: In the screen shot above we can see the microagent ‘name’ and ‘nameWithInstance’. Calling the Hawk REST API — Calling an Hawk method for a given BW 6.X Hawk micro-agent . This can be done with the following method POST /{domain}/{dns}/{agent}/invoke . Calling the method We have to use the domain, dns and agent name we got from the previous call. We also have to create a body for the call, for example to call the ‘GetApplicationDetails’ method of the BW 6.X Hawk microagent we have to create the following body (note that we have to use the microagent ‘nameWithInstance’ we got from the previous call): { “microagent”: “AS04-AN02-HMA:0”, “method”: “GetApplicationDetails”, “param”: { } } . Click ‘Try it Out’ . Check the output In a generic JSON format we have the list of deployed applications in the target appnode and details for each application including its name, version and state. Calling the Hawk REST API — Calling an Hawk method for a given BW 5.X Hawk micro-agent . This can be done with the following method POST /{domain}/{dns}/{agent}/invoke (as for BW 6.X) . Calling the method We have to use the domain, dns and agent name using the approach explained earlier. We also have to create a body for the call, for example to call the ‘GetExecInfo’ method of the BW 5.X Hawk microagent we have to create the following body (note that we have to use the microagent ‘nameWithInstance’ we got using the approach explained earlier): { “microagent”: “ COM.TIBCO.ADAPTER.bwengine.bw514.HelloWorld.HelloWorld:0”, “method”: “GetExecInfo”, “param”: { } } . Check the result The output of the Hawk method is available in a generic JSON format.

This article is to explain how to use the bwagent REST API in BusinessWorks 6.X. It is important to secure the bwagent REST API and this is explained in this other article: https://community.tibco.com/articles/tibco-activematrix-businessworks/bw6x-security-how-to-secure-the-bwagent-rest-api-r3417/ API documentation The API is documented in the form of an interactive Swagger UI. The Swagger UI can be used with the following: # Start the bwagent with the apiserver option . Note that this can be done even if the ‘real’ bwagent is running on the server . go to the <TIBCO_HOME>/bw/6.X/bin directory . Launch the bwagent with the ‘apiserver’ option, like this ./bwagent apiserver (Linux) bwagent apiserver (Windows) # Navigate to the Swagger page . By default it is available on the 5555 port http://localhost:5555/index.html Using the API The swagger UI doesn’t allow to directly use the API but it provide all details needed to call the API. For example in the Swagger UI it is possible to get details on the /browse/appnodes method and to try it: Note that the methods are not really called from the Swagger UI, but in the results section you get the URL to use to call this method: This URL then need to be updated to be able to call the ‘real’ API exposed by the bwagent: . The /api part should be replaced by /bw/v1/ . The hostname refer to the host where the target bwagent is running . By default bwagents expose the REST API on the 8079 port So to call the /browse/appnodes method on my ‘TESTEM’ domain I have to use the following URL: GET http://localhost:8079/bw/v1/browse/appnodes?domain=TESTEM Then this URL can be used in a tool like Postman: Note that the bwagent port used to expose the REST API can be configured by adjusting the following property in the bwagent.ini file: bw.agent.http.port Reference elements https://docs.tibco.com/pub/activematrix_businessworks/6.9.1/doc/html/Default.htm#administration/accessing-the-bwagen.htm

While supporting a BusinessWorks or a BusinessWorks Container Edition configuration one important point is to make sure that you are using TIBCO products versions that are supported. This article is to explain how to check a given product version is supported and if an end of support date is already defined. Messaging products General elements about Messaging products (TIBCO EMS, TIBCO FTL, and etc…) support are available here: https://support.tibco.com/s/article/TIBCO-Messaging-Products-Supported-Platforms-End-of-Support-Information Specifically the end of support dates for Messaging products are available in the form of a Google sheet available at the following URL: https://docs.google.com/spreadsheets/u/1/d/1Ibq9eNIFLmozmdRDiozd42IhPgnaL3X5x45k0ZWEoqc/htmlview From that page you just need to select the tab corresponding to the product you want to check. For example for TIBCO EMS you have to display the EMS tab. In the screen shot above you can see that EMS 8.4 is no longer supported. In this other example below you can see that EMS 8.6 will be supported under RHEL 8.X until end of December 2024. In the additional example below you can see that EMS 10.2, that is the current EMS version, has no end of support date announced for most of the supported platforms. This means it will be supported at the very least for an extra year from the date you are checking and this is very likely to be more. Integration products End of support dates for Integration products, and other products, are available in the form of a WEB Page available at the following URL: https://support.tibco.com/s/end-of-support Enter the name of the product you are looking for in the Search area, and then look for the version you are using. In the example below we can see that BusinessWorks 5.13, 5.13.1 and 5.13.2 will reach end of support at the end of January 2024. In this other example below you can see that BusinessWorks 6.6.0 and 6.6.1 are no longer supported since July 2023 but Extended support is available, you can also see that BusinessWorks 6.7.0 will be supported under December 2024 and extended support will be available. Extended support is available at an extra cost and it is generally for an extra year of support. Note also that on the example above we don’t see Business 6.8.x and 6.9.x which are current versions with no end of support announced. This means those versions will be supported at the very least for an extra year from the date you are checking and this is very likely to be even more. In the case you won’t find a product or a version that would be relatively old in the ‘end of support’ page I would suggest to contact a TIBCO representative. Reference elements Reference elements from TIBCO support about end of support dates: https://support.tibco.com/s/article/Tibco-KnowledgeArticle-RetirementNotice-40036 Elements about platform support policy: https://support.tibco.com/s/article/Platform-Support-Policy-for-TIBCO-Products General elements about TIBCO support: https://docs.tibco.com/pub/tibco-support-guide/html/Default.htm

While installing a BusinessWorks 6.X configuration an important task not to forget is to secure the bwagent REST API. This new article explains how to implement this configuration best practice. #1 Update the bwagent.tra file . Go to the <TIBCO_HOME>/bw/6.X/bin directory . Edit the bwagent.tra file . Uncomment the following line #java.property.java.security.auth.login.config=%BW_HOME%/config/jaas.login.conf The file pointed by the property is the default JAAS configuration file, it contains a reference to the default bwagent realm properties file. By default this file is <TIBCO_HOME>/bw/6.X/config/realm.properties #2 Update the default admin user password in the bwagent realm properties file . By default the file contains an admin user with a default password (‘admin’) The format of the file is the following: <username>: <PASSWORD FORMAT>:<PASSWORD>, <ROLE> The two default users admin and bwappnode have an ‘admin’ role and can use all methods of the bwagent REST API. Roles are pre-defined in the bwagent (and independent from the roles managed in the TEA), the available roles are the following: admin, operator & user. Roles definitions are the following: Users with ‘admin’ role can performs all Operations (Create Domains, Appspaces, Appnodes, Upload/Deploy EAR, Start and Stop and Delete) Users with ‘operator’ role can only read and do lifecycle operations (start/stop components) Users with ‘user’ role only have read access . Choose a new password (for example ‘Tibco123’) . Go to the <TIBCO_HOME>/bw/6.X/system/lib/tea folder . Use Java with the -cp option to call the Jetty password utility This can be done with the following: java -cp jetty-util-<version>.jar org.eclipse.jetty.util.security.Password <username> <password> For example (in BW 6.8.1 with TEA 2.4.1) : java -cp jetty-util-9.4.44.v20210927.jar org.eclipse.jetty.util.security.Password admin Tibco123 . Update the bwagent realm properties file with the new password (using the CRYPT format) For example: . Save the file and restart the bwagent (if you want to test the change) #3 Update the default bwappnode password in the bwagent realm properties file . By default the file contains a bwappnode user with a default password . Choose a new password (for example ‘AppNode123’) . Encrypt the new password as explained above for the admin user . Update the bwagent realm properties file with the new password (using the format of your choice but the CRYPT format is the most secure) For example: There is nothing more to do while this is the bwagent sharing the password to use with the appnode. . Save the file and restart the bwagent (if you want to test the change) #4 Create additional users (if needed) In case the bwagent REST API would be used for other purposes, like monitoring the configuration or doing basic administration tasks, additional users can be created and set to a role supporting the minimum needed access rights. To create a user with read only access to the bwagent REST API you can do the following: . Choose a name and a password (for example monitor and ‘Mon123’) . Encrypt the new password as explained above for the admin user . Add a line for the new user in the bwagent realm properties file For example: monitor: CRYPT: mo12/2gQkJ3v.,user . Save the file and restart the bwagent #5 Testing the configuration Example of the admin user calling the agent/refresh method: Example of the monitor user calling the browse/appspaces method: Additional elements The BusinessWorks MAVEN plugin must use a user with the ‘admin’ role. Additional configuration options are available to: . Use a Digest authentication instead of a Basic authentication . Connect the bwagent to an Enterprise Directory using LDAP or LDAPS . Configure the bwagent to expose its REST API over HTTPS All these options are detailled in the BusinessWorks documentation. Reference elements Reference elements about securing the bwagent REST API are available in the BusinessWorks administration guide in the ‘Securing the bwagent REST API’ section: https://docs.tibco.com/pub/activematrix_businessworks/6.10.0/doc/html/Default.htm#administration/securing-the-bwagent.htm

By default when a BusinessWorks application is started all its Process Starters, or Components, are started meanwhile in some use cases it is useful to disable a Process Starter at start-up and to enable it in a later stage either within the BusinessWorks application logic or from an external component. This article is to explain how to do this in different way: . Using the TEA . Using the bwagent REST API . Using a bwadmin command It is important to keep in mind that this configuration is persisted locally on the BusinessWorks server and disabling or re-enabling the automatic start for a Process Started will be in effect at the next application start-up even if the Process Starter is enabled or disabled while the application is running. How to configure a Process Starter or Component Auto Start using the TEA By default all Process Starters or Components of an application are configured to start when the application is started (‘Auto Start’ enabled). This can be updated using the ‘Applications’ panel of the TEA, selecting an application, opening the ‘Components’ tab, selecting a Process Starter or Component and then updating the ‘Auto Start’ option. Note that this configuration is managed at application level (for all appnodes). How to configure a Process Starter or Component Auto Start using the bwagent REST API A Process Starter or Component Auto Start can be disabled using the following bwagent REST API method: PUT /bw/v1/domains/<DOMAIN_NAME>/appspaces/<APPSPACE_NAME>/applications/<APPLICATION_NAME>/<VERSION>/component/autostart/disable?components=<COMPONENT_NAME> Example: PUT http://localhost:8079/bw/v1/bw/v1/domains/TESTEM/appspaces/AS04/applications/TestApp.application/1.0/component/autostart/disable?components=ComponentJMSReceiver A Process Starter or Component Auto Start can be re-enabled using the following bwagent REST API method: PUT /bw/v1/domains/<DOMAIN_NAME>/appspaces/<APPSPACE_NAME>/applications/<APPLICATION_NAME>/<VERSION>/component/autostart/enable?components=<COMPONENT_NAME> How to configure a Process Starter or Component auto start using bwadmin A Process Starter or Component Auto Start can be disabled using the following bwadmin command: disablecomponentautostart -d <DOMAIN_NAME> -a <APPSPACE_NAME> <COMPONENT_NAME> <APPLICATION_NAME> <VERSION> Example: disablecomponentautostart -d TESTEM -a AS04 ComponentJMSReceiver TestApp.Application 1.0 A Process Starter or Component Auto Start can be re-enabled using the following bwadmin command: enablecomponentautostart -d <DOMAIN_NAME> -a <APPSPACE_NAME> <COMPONENT_NAME> <APPLICATION_NAME> <VERSION> How to enable a Process Starter or Component at runtime within BusinessWorks A Process Starter or a Component disabled at start-up can be enabled at runtime within the BusinessWorks application logic using the ‘Engine Command’ activity configured with the ‘ResumeProcessStarter’ Command and the target Process definition name. This action is only for the current runtime environment and at the next application start-up this is the ‘Auto Start’ configuration of the Process Starter or Component that will apply. Similarly, a Process Starter or a Component can be disabled at runtime within the BusinessWorks application logic using the ‘Engine Command’ activity configured with the ‘SuspendProcessStarter’ Command. How to enable a Process Starter or Component at runtime using the bwagent REST API A Process Starter or a Component disabled at start-up can be enabled at runtime using the following bwagent REST API method: POST /bw/v1/domains/<DOMAIN_NAME>/appspaces/<APPSPACE_NAME>/applications/<APPLICATION_NAME>/<VERSION>component/<COMPONENT_NAME>/start This action is only for the current runtime environment and at the next application start-up this is the ‘Auto Start’ configuration of the Process Starter or Component that will apply. Example: http://localhost:8079/bw/v1/domains/TESTEM/appspaces/AS04/applications/TestApp.application/1.0/component/ComponentJMSReceiver/start Similarly, a Process Starter or a Component can be disabled at runtime within the BusinessWorks application logic using the following bwagent REST API method: POST /bw/v1/domains/<DOMAIN_NAME>/appspaces/<APPSPACE_NAME>/applications/<APPLICATION_NAME>/<VERSION>component/<COMPONENT_NAME>/stop