Data Feed Trigger

[SergeiBakhaev]

Hello everyone!

I have quite a lot of data feeds that runs every 5 minutes to keep up with data changes.

If I'm not wrong, in one of the FFTH I've heard something about service/app, that could listen for changes in Archer and trigger Data Feed.

Have anyone aware of this?

Best regards,

Sergei

[Ilya_Khen]

Not sure about servlet, but maybe it is coming from here as a beginning: https://community.rsa.com/docs/DOC-62020 

[SergeiBakhaev]

I know about custom object to trigger DF, but no, this was different thing.

Actually, I found where I've heard it.

Scott Hagemeyer‌'s FFTH on RSA Archer Release 6.4: Integrations Enhancements.

At 34:40 there is talk I've mentioned.

[Anonymous · Accepted solution]

You are looking for Bodie Minster‌'s utility on the RSA Exchange for RSA Archer" data-type="space‌:

https://community.rsa.com/docs/DOC-95943 

[SergeiBakhaev]

Thanks,

Yes, that's the tool I was looking for.

Actually, I'm already using it almost for a month in production. Forgot to close my answer.

[Anonymous]

Glad to hear it! How is the utility working for you?

[SergeiBakhaev]

Quite good! I'm using mostly file monitor, and without need of launching df every few minutes, job processing works more stable.

However, I found that if there are too many monitors in the config (about 10-15 in my case), tool itself spends more than a minute or two to check them all. Still looking into the problem.

[Anonymous]

Hmmm... Bodie Minster‌, any thoughts on the above?

[BodieMinster]

It sounds plausible that it could take 1-2 minutes to verify files. The time it takes to check each one would depend on a number of factors which could include things like:

• Is it stored on a network share, or is the storage local to the utility?
• If it's on a network share, how many hops exist between the utility and the storage?

It should be possible for us to thread the execution of each data feed monitor so that some number of them can run concurrently. What are your thoughts on a reasonable number of threads? 10 maybe?

[SergeiBakhaev]

Thanks for reply,

I've looked into logs, and it looks like it's not the monitors itself takes time. There is a big delay between Logging Init and first CheckMonitors():

11.15.2018 08:57:00.779 :: INFO :: [LoggingInit] :: Logging Initialized
11.15.2018 09:06:28.112 :: INFO :: DataFeedMonitor.CheckMonitors() :: Checking criteria for monitor DF1 (A2A).
11.15.2018 09:06:28.727 :: INFO :: DataFeedMonitor.CheckMonitors() :: Criteria not met.
11.15.2018 09:06:28.732 :: INFO :: DataFeedMonitor.CheckMonitors() :: Checking criteria for monitor DF2 (A2A).
11.15.2018 09:06:30.038 :: INFO :: DataFeedMonitor.CheckMonitors() :: Criteria not met.
11.15.2018 09:06:30.039 :: INFO :: DataFeedMonitor.CheckMonitors() :: Checking criteria for monitor DF3 (A2A).
11.15.2018 09:06:31.164 :: INFO :: DataFeedMonitor.CheckMonitors() :: Criteria not met.
11.15.2018 09:06:31.167 :: INFO :: DataFeedMonitor.CheckMonitors() :: Checking criteria for monitor DF4 (A2A).
11.15.2018 09:06:32.275 :: INFO :: DataFeedMonitor.CheckMonitors() :: Criteria not met.
11.15.2018 09:06:32.283 :: INFO :: DataFeedMonitor.CheckMonitors() :: Checking criteria for monitor DF5 (A2A).
11.15.2018 09:06:33.537 :: INFO :: DataFeedMonitor.CheckMonitors() :: Criteria not met.
11.15.2018 09:06:33.555 :: INFO :: DataFeedMonitor.CheckMonitors() :: Checking criteria for monitor DF6 (А2А).
11.15.2018 09:06:34.138 :: INFO :: DataFeedMonitor.CheckMonitors() :: Criteria met, executing feed D393B502-D97C-451D-A538-24C7FDA1FC39.‍‍‍‍‍‍‍‍‍‍‍‍‍

And in this case all of the monitors are Archer-to-Archer ones.