Hi Atul,

Am I understanding this correctly? You created a shell script? Like a BASH script or something similar with a .sh extension?

Regards,

Jon

Yes the script with .sh extension.


Regards
Atul

Hi Atul,

So you made a shell script that is going to fetch data from the database, modify the data, and then re-insert it back into the database?

Is there a reason why you're choosing to use a shell script directly on the server to accomplish this? Are these database tables coming off of the LabKey database? Have you considered using our APIs instead?

Generally, browsers cannot normally interface with any files directly on the operating system since there is a layer between them that normally cannot be bypassed unless if something else is used as a medium, like a Java applet or similar. We do have scripting engines that potentially could trigger that shell script, but this kind of setup is very odd and also poses some security risks as well since you normally don't want the browser to execute anything on the server unless it is tightly controlled.

Regards,

Jon

Dear Jon,

The scenario is, I want to trigger an application (out of labkey scope). That software uses labkey java api to get access of labkey database.

However, two main issues i am facing,

1. To trigger that application.
(Is it possible that I can write a new java module in labkey for the same? Or use the scripting engine that you've mentioned above).

2. How can I use external schemas (other that labkey database which is configured in labkey.xml)?

As the JAVA API is able to fetch data from lists or tables present in labkey database's schemas.

But I have configured one more database in labkey.xml, when api is trying to access tables from that database, An internal server error occurs.

Please help.

Regards
Atul

Hi Atul,

It might be possible to add the .sh script to your External Scripting engine and within a report have the script get triggered, but this hasn't been tested so I can't promise that it will work and it really isn't properly supported to do that. It may also be possible to use another scripting language, such as Python or Perl and use that script to trigger your shell script. You could build a Java module to trigger this script as well, but this extensibility goes beyond what we would support for the LabKey platform.

With regard to the external schemas, they are only recognized within LabKey if they are configured in the labkey.xml. We have no other way of accessing databases otherwise as external schemas.

When you say that you are getting an internal server error when trying to access an external schema and table via the LabKey API, can you give us some more details? What API are you trying to use? Can you view the data within LabKey itself? What is the exact error you're receiving? Can you provide us with the stack error that appears when you do try to access the data?

Regards,

Jon

Dear Jon,

Internal server error: Fixed the issue as I was passing the wrong URL format while creating connection to labkey(Using api)

Instead of using Connection "cn = new Connection("http://localhost:8080/labkey")", I was using "cn = new Connection("jdbc:labkey:http://localhost:8080/labkey").
Hence Fixed.

Now the second problem of invoking shell script:

Could you please elaborate more about "It might be possible to add the .sh script to your External Scripting engine and within a report have the script get triggered."

Are you talking about this (Please Refer the link below)?:
https://www.labkey.org/Documentation/wiki-page.view?name=configureScripting

Hi Atul,

I don't have any more details on that. It was an idea one of our developers had, but I'm not certain as to how this would work.

Setting up the scripting engine to point to /bin/bash for example only tells the LabKey platform that if it sees a .sh script, that it can execute it. However, the only other places where I've seen script execution like this would be within a transformation script for assays, which is different than what you're trying to do.

Let me see if I can get more details and get back to you.

Regards,

Jon