Monitoring IBM App Connect Professional Projects

This article describes a project that can be used to monitor projects in App Connect Professional (formerly known as Cast Iron) that are running in a physical or virtual appliance, or in Docker or Kubernetes. The project takes a list of projects as input and checks periodically if the projects are running. If the projects aren’t running (for example, they have stopped, been suspended, or are not deployed), each project is started and changed to running state. A report (as comma-separated values) is also generated and logged with a list of the projects and their state. This project has two main orchestrations, each of which handles a specific use case (a stand-alone appliance and appliances that are configured for high availability).

Project name: MonitoringCastIronProjects
Download location: From the App Connect Professional Studio menu Solutions>Search for TIPs, search for the project template by using keywords like “monitoring” or “HA”.

Use cases:

• One orchestration, singleApplianceMonitoring_orch, is used to monitor a stand-alone appliance that contains a set of projects. The orchestration is triggered by using a scheduler that runs every hour at 30 minutes after the hour or is triggered manually by making a REST call to https://, where hostname is the management IP address or host name.
• Another orchestration, multipleApplianceMonitoring_orch, is used to monitor more than one appliance that contains the same set of projects in all these appliances. This orchestration is applicable to cases where the appliances are configured for high availability (both failover and/or load distribution). Each of the projects can be designated to run in only one appliance or to run in all the appliances.
  The orchestration is triggered by using a scheduler that runs every hour at 30 minutes past the hour or is triggered manually by making a REST call to https://, where hostname is the management IP address or host name.

Projects or appliances can be configured for high availability by using IBM WebSphere Datapower SOA Appliances or another load balancer, or you can develop a simple orchestration that distributes the load in a “round robin” fashion.

If you’re using only one appliance, you can disable the other orchestration in this project and run just what is needed. This monitoring project can be deployed to the same appliance that’s being monitored. If you have multiple appliances, deploy this project to just one of the appliances.

Prerequisites:

• The configuration file needs to contain a list of appliances and projects. For more details, see the configuration section.
• The “factory supplied identity” certificate in the keystore of each of the appliances needs to be exported and imported into the appliance truststore on which this project is running. This is necessary to make the management API calls and manage the lifecycle of a project. This step needs to be performed in the Web Management Console.

Configuring a stand-alone appliance

1. Make a list of projects that need to be monitored. You don’t have to monitor all projects in the appliance; list only those projects that need to be monitored.
2. Create a valid JSON configuration to capture the appliance details and the list of projects that are to be monitored. A sample JSON structure is given below.
   {
"applianceList": [
{
"applianceHostName": "hostname.ibm.com",
"applianceUserName": "userName",
"appliancePassword": "password"
}
],
"projectsList": [
{
"projectName": "project1ReSTAPI",
"projectVersion": "1.0",
"configurationName": "Default",
"delayinSeconds": 15
},
{
"projectName": "Project2OData",
"projectVersion": "2018.5.5",
"configurationName": "Default"
}
]
}

   This sample contains appliance details and information for two projects. You can also add an optional property, delayInSeconds, for each project, which indicates the wait time for a project to start fully. The default value is 10 seconds. You can provide a custom value if a project is complex and takes more than 10 seconds to start completely. This wait time indicates how long to wait after a project has started before checking its status.

3. This JSON content is given as input in the map input of the “Read JSON” activity of the project. You can customize and extend this project to read a JSON configuration file from an FTP server and pass it to the “Read JSON” activity.
4. After you save the project, you can deploy and test it.
5. The scheduler is triggered every hour at 30 minutes past the hour. You can also trigger it manually by accessing the URL https://applianceHostname/singleApplianceMonitor.

Steps for multiple appliances that are configured for high availability

1. Make a list of projects that need to be monitored. You don’t have to monitor all projects in the appliance; list only those projects that need to be monitored. The projects in this list must be available in all the appliances.
2. Create a valid JSON configuration to capture all the appliance details and the list of projects that need to be monitored. A sample JSON structure is given below.
   {
"applianceList": [
{
"applianceHostName": "hostname1.ibm.com",
"applianceUserName": "userName",
"appliancePassword": "password"
},
{
"applianceHostName": "hostname2.ibm.com",
"applianceUserName": "userName",
"appliancePassword": "password"
}
],
"projectsList": [
{
"projectName": "process_accounts",
"projectVersion": "1.0",
"configurationName": "Default",
"singleton": true,
"delayinSeconds": 5
},
{
"projectName": "testProject",
"projectVersion": "1.0",
"configurationName": "Default",
"singleton": false,
"delayinSeconds": 20
}
]
}

   This sample contains details of two appliances and information for two projects. The two projects must be available in the two appliances specified in the configuration.

   You can also add an optional property, delayInSeconds, for each project, which indicates the wait time for a project to start fully. The default value is 10 seconds. You can provide a custom value if a project is complex and takes more than 10 seconds to start completely. This wait time indicates how long to wait after a project has started before checking its status.

   A property called singleton is also provided for each project. This property indicates whether the project is running in all the appliances or just one appliance:

   • If singleton is true for a project, the project runs in just one appliance out of the list of configured appliances. The project will be in “undeployed” state in all other appliances. This is equivalent to the project being in standby mode in all other appliances.
   • If singleton is false for a project, the project runs in all the appliances that are specified in the input configuration. This property can be used to load balance work among all running projects.
3. This JSON content is given as input in the map input of the “Read JSON” activity of the project. You can customize and extend this project to read a JSON configuration file from an FTP server and pass it to the “Read JSON” activity.
4. After you save the project, you can deploy and test it.
5. Another helper orchestration (singleton_running_status_orch) is used to cache project status when singleton is set to true for some projects.
6. The scheduler is triggered every hour at 30 minutes past the hour. You can also trigger it manually by accessing the URL https://applianceHostname/multipleApplianceMonitor.
7. Here is an example of a report, in CSV format, that is logged:
   Host Name","Singleton","Project Name","Version","Configuration Name","Status"
"hostname.ibm.com","project1ReSTAPI","1.0","Default","STOPPED to UNDEPLOYED to RUNNING"
"hostname.ibm.com","","Project2OData","2018.5.5","Default","RUNNING"
"hostname.ibm.com","Scheduler3Test","1.0","Default","UNDEPLOY to RUNNING"

Customization and extensions

The project can be customized further based on your requirements.

• The configuration file that contains the list of appliances and projects can be stored on and read from an FTP server so that the project doesn’t need to be edited when the configuration file is changed.
• The password of the appliance can be stored in an encoded or encrypted format and the password can be decoded or decrypted (after the “Read JSON” activity) before it is used. You can generate the encoded or encrypted password by using App Connect Professional activities, and store it in the file.
• The time that is configured in the scheduler activity can be adjusted for your requirements.
• The report is generated in CSV format and is logged by using the log activity. The project can be customized to store the CSV content as a file on the FTP server, or send it as an email, by using FTP or email activities.