How to compile java udf on nodes

Database
Highlighted
Junior Supporter

How to compile java udf on nodes

Hi,

I have a java UDF that i need to install on TD. I want to copy the jar file to TD server and compile . I read throught the manuls for the steps to do so. Below is my understanding. I want to know if my understsing is correct ?

 

1. Find the default path for source code on the node by command "cufconfig -o" and copy the .JAR files there. Suppose default path is - /etc/opt/teradata/tdconfig/Teradata/tdbs_udf/usr/. I create another folder java_xsp and copy my JAR file there. Say my file name is - test.jar

2. Run this command on the node,

DATABASE mydb;
CALL SQLJ.INSTALL_JAR('SJ!java_xsp/test.jar', 'test_JAR', 0);

3. Now the manual talks about - "distribute the JAR file to all nodes". My question is -  is there any other command to do this ? or CALL SQLJ.INSTALL_JAR that i executed earlier on one node would do this for me ? Do i need to login to other nodes and run CALL SQLJ.INSTALL_JAR again ? Any details on his will really help.

4. Are there any more steps to be done that i missed above ?

 

Thx! Samir

4 REPLIES
Teradata Employee

Re: How to compile java udf on nodes

If you use the SJ option then you must ensure that the jar file is available at the same file location on all nodes, and has the correct permissions to be accessible by the Teradata Database process.

 

It's easier to use the CJ option to obtain the jar file from the client system. Put the jar file in your current directory on your client system and execute BTEQ commands like the following:

 

DATABASE mydb;
CALL SQLJ.INSTALL_JAR('CJ!test.jar', 'test_JAR', 0);

Enthusiast

Re: How to compile java udf on nodes

 
Junior Supporter

Re: How to compile java udf on nodes

Thx tomnolan for replying. I have few further questions on this. It would be helpful if you could reply to these.

 

1. If you use the SJ option then you must ensure that the jar file is available at the same file location on all nodes, and has the correct permissions to be accessible by the Teradata Database process.

--the file location would come from the output of - "cufconfig -o" in SourceDirectoryPath field right ? Also, do i need to go and run below command on every node ? What is meant by "distribute the JAR file to all nodes" ?

DATABASE mydb;
CALL SQLJ.INSTALL_JAR('SJ!java_xsp/test.jar', 'test_JAR', 0);

surprisingly, the output of "cufconfig -o" on my node shows - /etc/opt/teradata/tdconfig/Teradata/tdbs_udf/usr/, but i dont find the folders after - /etc/opt/teradata/tdconfig/. I have opened a ticket with GSC on this. But, would you have any ideas about this ? What are correct permissions here ?

 

2. It's easier to use the CJ option to obtain the jar file from the client system. Put the jar file in your current directory on your client system and execute BTEQ commands like the following:

DATABASE mydb;
CALL SQLJ.INSTALL_JAR('CJ!test.jar', 'test_JAR', 0);

--This command has to run on the node ? If i put the jar file on client system, would it not becomes local to that machine. So, if the machine moves out sometime, would that not be a problem ? Also, is it better not to put it on the DB nodes from a future DB migration(no different versions etc) perspective ? We face this problem now when upgrading. For some of the user UDFs, we dont get the source code as the person has moved out of organization. Please suggest.

Teradata Employee

Re: How to compile java udf on nodes

> the file location would come from the output of - "cufconfig -o" in SourceDirectoryPath field right ?

 

Correct. This is documented in the Teradata Database Reference / SQL External Routine Programming / Chapter 8: Administration / Registering and Distributing JAR and ZIP Files for Java External Routines.

 

 

> Also, do i need to go and run below command on every node ?

 

No, you do not run the "CALL SQLJ.INSTALL_JAR" command on every node. You only need to run that command once.

 

 

> What is meant by "distribute the JAR file to all nodes" ?

 

When you use the SJ option, you are responsible for copying your jar file to every Teradata Database node.

 

 

> surprisingly, the output of "cufconfig -o" on my node shows - /etc/opt/teradata/tdconfig/Teradata/tdbs_udf/usr/, but i dont find the folders after - /etc/opt/teradata/tdconfig/. I have opened a ticket with GSC on this. But, would you have any ideas about this ?

 

With the SJ option, you can specify a relative path, or an absolute path. If you specify a relative path, then the path is relative to the "cufconfig -o" SourceDirectoryPath. So if you specify a relative path, then you must also create any missing directories that are listed in the "cufconfig -o" SourceDirectoryPath. If you don't want to create those directories, then put your jar file into an existing directory on each node, and specify the absolute path to your jar file with the SJ option.

 

 

> What are correct permissions here ?

 

Your jar file must be readable by the "teradata" operating system user.
 


> use the CJ option to obtain the jar file from the client system. This command has to run on the node ?

 

When you use the CJ option, you can run the "CALL SQLJ.INSTALL_JAR" command on a node, or on a client system. It is typically run on a client system. You only need to run that command once.

 

 

> If i put the jar file on client system, would it not becomes local to that machine. So, if the machine moves out sometime, would that not be a problem ?

 

No that should not be a problem, because you should keep your Java source code in a source control system such as GitHub, and you should have a repeatable build process to rebuild your jar file when needed, and a repeatable deployment process to run the "CALL SQLJ.INSTALL_JAR" command to deploy your jar file to the database.

 

 

> Also, is it better not to put it on the DB nodes from a future DB migration(no different versions etc) perspective ?

 

No. Organizations typically have multiple database systems -- for development, test, production, disaster recovery. You should keep your Java source code in a source control system such as GitHub, and you should have a repeatable build process to rebuild your jar file when needed, and a repeatable deployment process to run the "CALL SQLJ.INSTALL_JAR" command to deploy your jar file to the database. With repeatable processes in place, you can easily deploy to a new database system.

 

 

> We face this problem now when upgrading. For some of the user UDFs, we dont get the source code as the person has moved out of organization. Please suggest.

 

You should keep your source code in a source control system such as GitHub.