Having files that do not contain SIL code is very common. Advanced scripters use a wide variety of file types to build their automation and integration solutions. Here are a few common types:
But why would you have non-code files in the SIL Manager, what is the purpose of them? The answer to that depends on what you are using the file for. Lets explore a little deeper.
My #1 use of non-SIL code files would be data. This is both data that can be read into a SIL script and data that is actually produced by a SIL script.
When I transitioned from someone who wrote SIL scripts for myself to someone who wrote SIL scripts for others I became a little self conscience about the quality of my code and looked for ways to keep things simple. As time passed I realized that I was using CSV data files in conjunction with my code. Not just some of the time, almost every time I had to write a complicated script. I soon realized that a lot of “logic” that would normally get added as code in the script could also be added to the data to simplify things even further. However, that topic is to large to cover here and will need to be another blog post.
Data isn’t just for importing into a script but for exporting as well. I have found many different examples of why it is helpful or even necessary to export data with a script. For example, how nice would it be to export a list of all the users in the system and the date that they last logged in to the system?
I will be creating more examples of importing/exporting data to help illustrate the value inherent in this ability.
Resources is such a generic term but I called them this on purpose because these could include anything that us needed to help your script work. Resources could include things like:
HTML or CSS
I have used Zip files when exporting the SIL code off the sever or perhaps to push data to an external FTP server.
HTML, CSS, and images are very common resources to use when sending email messages or creating new pages in Confluence. Usually, I use the SIL Template Language to dynamically generate the HTML, however, there are times where I externalize the CSS or when the email is basically static that I do not need the dynamic capability.
Logs or Reports
You absolutely have the ability to use the logPrint() routine to write to the Jira system log. However, there may be reasons why you wouldn’t want to do this. For example, searching through all those log messages can be time consuming. One option would be to create your own log using the printInFile() routine. This way, the log could be created in the silprograms folder and viewed from within the SIL Manager. I like to do this when testing SIL Listeners sometimes to be sure they are firing at the right times with the right information. However, you should be careful doing this because the file could grow extremely large so I only do this while debugging.
However, I have used this method to create reports for companies in highly regulated industries. I have created reports based on users login activity, when things like issues and projects get deleted, etc. SIL Listeners create a variety of opportunity to add additional tracking to Jira. A simple solution to the file size problem is dynamically name files based on the date so a single file can only be written to for a day. Then you can create a SIL scheduler to go in and clean up files in that folder that are older than 6 months (for example).
Some types of code files I have used in the SIL Manager:
Back in the day, before the HTTP routines were created, I used the system() routine quite often to user curl to sent REST calls. The HTTP routines have proven to be quite robust and I have not needed to use curl in a long time. However, once in a blue moon I find a REST API that is so bizarre and obviously hacked together that I need to revert to curl in order to use its extensive capabilities. I used to have the curl code in a .bat file that took parameters and had that file living out in the SIL Manager. It worked pretty well. Its is nice to know that that's still an option.
I have also used shell scripts to call other Java apps living on the system to create some really extraordinary integrations. For example, I have used Apache Tika to parse MS Word docs or PDFs into text files so I could read the contents using SIL. Sometimes I would try to integrate with systems that didn’t really have open API’s or that may have already had an integration created in another language like python. I found it easier just to call that python integration rather than reproducing it. There are many reasons why I would call other systems living on the Jira server from SIL.
There might be security and performance implications to calling other applications on the Jira server. However, if done properly some next-level integrations can be created this way.