Discussion:
Calling a remote AL using the AL FC
(too old to reply)
Franzw
2018-08-03 13:04:26 UTC
Permalink
Raw Message
I have struggled somewhat to understand how the Assemblyline FC works when calling a remote AL (an AL in a different Config).

I started out crating a project with a caller AL and a callee AL. That works as expected out of the box.. Just press the query box for the AL/Sequence and selct the correct AL - NP.

Then I copied the callee AL to a new project. ON the caller AL FC I clicked the query box for Config Instance (under advanced) - selected new project and redid the query for the AL and verified that I could only select ALs in the new project. But when I run the caller AL it will fail because it cannot find the config file...

It took me while to figure out what is going wrong....

Now - if i ran the callee AL in the TDI Config Editor then it gets loaded - one can see the name of the AL/config on the server object (normally in the lower left corner of the UI) and slowly I started to remember of how to load/start ALs using CLI I had been through a couple of years ago...

I think this small snippet is providing the needed knowledge in a very dense format :-) : http://www.gattis.org/Work-and-Tech/iam/tivoli/auto-starting-configs

So I now know what is needed - but I want to do this from the caller AL - and I am pretty sure it can - but I do not know how (yet) hence this post...

TH AL FC can connect and retrieve configs from remote AL Configs given a server (hostname:port) and access authorization. So this should also enable the FC of loading the config before calling it - this is clearly not happening (7.1.1 FP8). Not very friendly and somewhat confusing IMHO. But as always with TDI it should be easily done in a hook - I just need to find out the correct methods to call...

Can somebody help ?

Regards
Franz Wolfhagen
j***@gmail.com
2018-08-06 05:30:04 UTC
Permalink
Raw Message
Unfortunately, currently the AL FC does not start (load) a config instance as needed, the config instance must be already loaded.

You can add code like this in the Before Initialize Hook of the AL FC to work around the problem:

var fc = thisComponent.getFunction();
var server = fc.getParam("server")
var configID = fc.getParam("config")
var sess = fc.connectServer(server);
var configInstance = sess.getConfigInstance(configID);
if (configInstance == null) {
task.logmsg("starting " + configID)
configInstance = sess.startConfigInstance(configID);
}

This will start the config instance if it is not already loaded.
You could also add code to unload the config instance after the AL FC has finished.

If you feel that the AL FC should automatically do this for you, without having to add code in a hook, then just open a PMR for this. I too feel the current behavior is not intuitive.

You probably already know this: For the remote server to be able to find
the remote config given the ID, the configuration file for that ID must be in the configs folder (or the folder named by api.config.folder).
Franzw
2018-08-06 08:06:11 UTC
Permalink
Raw Message
Post by j***@gmail.com
Unfortunately, currently the AL FC does not start (load) a config instance as needed, the config instance must be already loaded.
var fc = thisComponent.getFunction();
var server = fc.getParam("server")
var configID = fc.getParam("config")
var sess = fc.connectServer(server);
var configInstance = sess.getConfigInstance(configID);
if (configInstance == null) {
task.logmsg("starting " + configID)
configInstance = sess.startConfigInstance(configID);
}
This will start the config instance if it is not already loaded.
You could also add code to unload the config instance after the AL FC has finished.
If you feel that the AL FC should automatically do this for you, without having to add code in a hook, then just open a PMR for this. I too feel the current behavior is not intuitive.
You probably already know this: For the remote server to be able to find
the remote config given the ID, the configuration file for that ID must be in the configs folder (or the folder named by api.config.folder).
Thanks - just what I needed. I was plowing through the Server API reference yesterday and found most of this.

I am still wondering about one thing - configs you work with are normally are normally stored directly in the associated workspace folder/directory as this explains the query config works with an empty soldir (Default server) config folder. So it should be possible to basically dynamically load configs associated to workspace - not server - so how can one retrieve the possible workspace folders - i.e. when the Eclipse UI starts it asks for workspaces - can this be done remotely ?

But in general my conclusion is that you need to know where the config is stored to load it as this information is required in the startConfigInstance() methods...

Thanks for you help - hope I can pay back by getting this better described somewhere...

Regards
Franz Wolfhagen
j***@gmail.com
2018-08-07 10:17:02 UTC
Permalink
Raw Message
The workspace is exclusive to the Configuration Editor (Eclipse UI).
The TDI server does not know anything about the workspace, and does not have any idea where Eclipse has worked.

If you want the TDI server to easily find configuration files, you should place them in the configs folder (api.config.folder). This allows you to use startConfigInstance() with only the ID, the file name is not needed in this case.
And as you mentioned earlier, if the com.ibm.di.server.autoload has a value, any configuration files found there will be automatically started when the TDI server is started with the -d flag.
Franzw
2018-08-07 10:45:12 UTC
Permalink
Raw Message
Post by j***@gmail.com
The workspace is exclusive to the Configuration Editor (Eclipse UI).
The TDI server does not know anything about the workspace, and does not have any idea where Eclipse has worked.
If you want the TDI server to easily find configuration files, you should place them in the configs folder (api.config.folder). This allows you to use startConfigInstance() with only the ID, the file name is not needed in this case.
And as you mentioned earlier, if the com.ibm.di.server.autoload has a value, any configuration files found there will be automatically started when the TDI server is started with the -d flag.
I would say that this was as expected :-) and I knew that I could do this via the configs folder.

Now - the reason I am asking these questions is that I want to make a solution where I basically could fire off an AL on a remote server without anything else than enough credentials to be allowed to so. And I am pretty sure I can do this using Session.startTempConfigInstance().

Session.startTempConfigInstance() requires a config represented as a String object (xmlConfig) which removes the problem of managing configs on the remote server. In my solution I would like to take my current config (locally - without having to deal with configs locally either), convert it to xml and fire it off on the remote server.

One way of doing this is to save the config in e.g. a script node and retrieve the xml from there - but this is a rather crude way - it would be more elegant (and much easier to maintain) if I just could retrieve the xml from the current session - but this looks more or less impossible - the closest I could find is that the BaseConfiguration has a toEntry() method - but I do not know if I can get a valid config xml from that...

Regards
Franz Wolfhagen
j***@gmail.com
2018-08-08 02:50:08 UTC
Permalink
Raw Message
Hi Franz,

here is some code that allows you to convert the running configuration to a string.

---
// Get the MetamergeConfig that this AL is a part of
var conf = main.getMetamergeConfig();
// Save it to an internal byte array and convert that to a String
var bos = new java.io.ByteArrayOutputStream();
conf.commitChangesNoEncryption(bos);
var xmlString = bos.toString("UTF-8");
---

Regards,
Jens Thomassen
Franzw
2018-08-08 09:59:50 UTC
Permalink
Raw Message
Post by j***@gmail.com
Hi Franz,
here is some code that allows you to convert the running configuration to a string.
---
// Get the MetamergeConfig that this AL is a part of
var conf = main.getMetamergeConfig();
// Save it to an internal byte array and convert that to a String
var bos = new java.io.ByteArrayOutputStream();
conf.commitChangesNoEncryption(bos);
var xmlString = bos.toString("UTF-8");
---
Regards,
Jens Thomassen
So simple if one just had found the right method... :-)

Invaluable help - thanks Jens.

Regards
Franz Wolfhagen

Loading...