This is one of the things I like most about CPI: it has a very cooperative and active community. Without going too far, some of the best sessions I attended at Teched this year were hosted by community members. One other good example happened last week. Piotr Radski suggested that CPI should offer more information on iFlows that have scheduled triggers. A feature that doesn't currently exist in CPI. His post, in a short time, received many suggestions and even the SAP´s product managers validated his request (so we might have news soon).
This comment encouraged me to explore ways in which this information can be gathered. And I have good news: I managed to find an efficient way to read this information and also, I've built a rudimentary Iflow that is open source so it can be improved. This first post examines the way I got the information.
TL;DR? Get the Iflow here.
Some of the suggestions in the original question indicated that this could be achieved if the scheduler was externalised. However, this does not necesarily reflect the reality of the objects that are currently depoyed. For example, the parameter could be changed without ever deploying the change. Whilst reading the community opinion I came across this comment of 7a519509aed84a2c9e6f627841825b5a:
Me: ...
The first thing was to download an iflow that was active and see how the scheduling processes were recorded. I found that inside the /OSGI-INF/blueprint/beans.xml file, among other things, it is shown that artifacts use Quartz as a job manager. The most remarkable thing about this is that it is possible to directly access the cron expression that controls the execution of the process. Eureka! (If you are not familiar with cron, take a look at the crontab man page)
The second step was to use the solution proposed by Morten to read the currently deployed iFlows. By reading and taking as reference the example script that he left in his blog, it was not complicated to do it.
The third point was to be able to interpret the cron expression, so that I could calculate the next executions. It was at this point where I had more problems since I couldn't make the libraries work properly despite being well documented. Also I wasn't clear in which time ranges I should evaluate the cron expression. Shame on me!
Finally, I needed to find a way to expose the information. I did it in three ways: dump raw information of the iFlows, transform the information to include future execution data, and finally use a JavaScript library to present timelines.
The result of all this was what I call TSMI (The Scheduled Iflows Monitor). Hopefully good suggestions and collaborators will come to improve this monitor until SAP releases a better option.
Going back to how I started this article, I like the SAP integration community. This community motivates you to look for solutions and at the same time helps you find the answers you need. Thank you community!
Ariel Bravo Ayala
To learn more about TSMI, see the following article:
TSIM: The Scheduled Iflows Monitor
You can read the full thread here.
This comment encouraged me to explore ways in which this information can be gathered. And I have good news: I managed to find an efficient way to read this information and also, I've built a rudimentary Iflow that is open source so it can be improved. This first post examines the way I got the information.
TL;DR? Get the Iflow here.
How to read the scheduling of a deployed iFlow?
Some of the suggestions in the original question indicated that this could be achieved if the scheduler was externalised. However, this does not necesarily reflect the reality of the objects that are currently depoyed. For example, the parameter could be changed without ever deploying the change. Whilst reading the community opinion I came across this comment of 7a519509aed84a2c9e6f627841825b5a:
Me: ...
The first thing was to download an iflow that was active and see how the scheduling processes were recorded. I found that inside the /OSGI-INF/blueprint/beans.xml file, among other things, it is shown that artifacts use Quartz as a job manager. The most remarkable thing about this is that it is possible to directly access the cron expression that controls the execution of the process. Eureka! (If you are not familiar with cron, take a look at the crontab man page)
The second step was to use the solution proposed by Morten to read the currently deployed iFlows. By reading and taking as reference the example script that he left in his blog, it was not complicated to do it.
The third point was to be able to interpret the cron expression, so that I could calculate the next executions. It was at this point where I had more problems since I couldn't make the libraries work properly despite being well documented. Also I wasn't clear in which time ranges I should evaluate the cron expression. Shame on me!
Finally, I needed to find a way to expose the information. I did it in three ways: dump raw information of the iFlows, transform the information to include future execution data, and finally use a JavaScript library to present timelines.
The result of all this was what I call TSMI (The Scheduled Iflows Monitor). Hopefully good suggestions and collaborators will come to improve this monitor until SAP releases a better option.
Going back to how I started this article, I like the SAP integration community. This community motivates you to look for solutions and at the same time helps you find the answers you need. Thank you community!
Ariel Bravo Ayala
To learn more about TSMI, see the following article:
TSIM: The Scheduled Iflows Monitor
- SAP Managed Tags:
2 Comments
