Youtube Gateway Live

[Gaby Zenz]

I have the inheritence structure base_script inherited by base_sfc inherited by project0_base which is then inherited by both project0_dev and project0_staging. It is a mess. But the reason I have done this is because I keep running into project ownership issues, while still wanting to have a project that contains all of my scripts for use downstream.

My current problem is related to Gateway Scripts, and who owns them. I need to use message handler Gateway Scripts to interact with my server filesystem, and they have to run through handlers. I have implemented a handful of functions akin to ls and cat. Anyway, I want these scripts to be owned by my base_script project, as it contains all the shared scripts, but this is what happens when I try to call a message handler pointed at the Gateway Scripts:

This is when I have the project marked for inheritance and marked disabled:

com.inductiveautomation.ignition.client.gateway_interface.GatewayException: com.inductiveautomation.ignition.client.gateway_interface.GatewayException: Project 'base_script' is disabled.

But if I enable the project it says this: com.inductiveautomation.ignition.client.gateway_interface.GatewayException: com.inductiveautomation.ignition.client.gateway_interface.GatewayException: Project 'base_script' is inheritable and cannot execute message handler scripts.

My guess is when the project is disabled, the message handlers are offline, fine. But if I activate the project, it rejects the message handlers because it is inheritable. But that's the whole point! I don't want to have to manually duplicate these across various active leaf projects, especially when they are system-wide scripts. So I am not sure what to do.

One thing I have considered is making a sibling project to base_sfc that is base_gatewayscripts because I can leave it as inheriting base_scripts but I can also leave it enabled and uninheritable. It's an unappealing workaround, and I don't even know that it would work. A leaf project thats sole purpose is to run gateway filesystem requests

Put all of the logic in project library scripts, in the "universe" project at the root of your hierarchy, if you must. Then, in leaf projects, use one-line calls to the appropriate logic from event scripts and message handlers. (I don't agree with your desire, but this is what you must do to achieve it.)

In this arrangement, universe and *_common contain only well-tested resources, and are only edited/modified in appropriate maintenance windows in production. (Edits to these will cause scripting restarts in the gateway in all projects under them.)

When developing something that will end up in one of these inheritable projects, use a testing leaf project below it for your development work. When well tested, send the resources to the appropriate inheritable project and delete the testing project.

Note that perspective_common is the appropriate place for re-usable Views, and vision_common in the right place for reusable windows and templates. All other inheritable projects only contain project library scripts.

What is really frustrating is what I want is something that can allow me to invoke gateway scripts from anywhere without having to go through the rigamarole of setting up hardcoded gateway scripts that simply reflect back to project scripts but run in the gateway scope. It makes it very annoying to do filesystem IO.

Vision clients and the gateway are truly separate processes, even if running in the same computer. Some form of messaging or RPC is required. Ignition system calls that need gateway action do the RPC for you. If you have a custom requirement, you have to do the RPC yourself (system.util.sendMessage() or system.util.sendRequest()). Without RPC, all scripting is confined to the JVM in which it runs. Full stop.

Yes, I understand. I just wish they could be handled more fluidly than the static Gateway Scripts. I tried calling a project script from within the gateway script (on a project that definitely has the script available) and it didn't really work.

Ignition's setup works the way it does so that all scripting that runs in the gateway needs to pre-exist in a project. No dynamic code, short of python eval, which itself would have to pre-exist in a project.

Ignition's setup works the way it does so that all scripting that runs in the gateway needs to pre-exist in a project. No dynamic code, short of python eval, which itself would have to pre-exist in a project.

On top of that, the callback is itself code in the local JVM, not in the gateway JVM, so how do expect it would work?

What if callback is a path to a script in the project library specified? It doesn't need to execute arbitrary code any more than a project script might, just invoke it without having a hardcoded in-between function. It would be conceptually the same as

I wasn't really suggesting executing truly arbirary code, I realize thats a massive security issue (although if it's all internal to Ignition... ). Just a way to run establish project script code that won't actually function if within the project scope.

It should be all internal to Ignition, but it is theoretically possible to spoof/alter the behavior of a Vision Client. That's the whole point of things like cutting off Legacy DB permissions. (Yeah, it would have to be a determined attacker, but Ignition is used in infrastructure applications that would be potential targets of hostile nation-states.)

I have looked down this road before and I didn't manage to make it work -- I ran into an issue that perhaps you know how to solve: what do I feed to getattr()? What is the object that I can hand it that will give me access to the scripts? I just tried the following and it crashed my gateway (thats why you get a screenshot and not formatted code). The payload I handed it was "projectName": "myProject", "callback": "MyScripts.ls", "args": [], "kwargs": . Printing out globals() showed "MyScripts" in the output. Normally I wouldnt try to hand back the result but I am trying to crawl my way down and check out what's going on.

You're on the right track. But the project name part is moot, as the message handler is inside a project, and it is that project's scripts that will be exposed in globals(). If you want to access all of your projects like this, put such a message handle in each of them. Then the caller can target any project they like.

The projectName field is half vestigal half this-is-how-my-version-of-a-builtin-would-work so that they can access other projects, although I guess I understand if thats not ok from a security perspective.

In general, I feel that if I have to copy-paste a function into a bunch of different places, it means that there is something wrong with the ability of the system to communicate internally. Hence a unified system command! With all kinds of error handling and documentation.

Thats sort of how it is now, base_script is the equivalent of universe at the moment, I will refactor the projects some time in the coming weeks. Still spiritually opposed to copy-pasting boiler code regardless of the number of lines.

Unfortunately I do not know how to do this. I don't write in Java, so while I am sure I could do this with enough effort, it is not worth the investment for me at the moment. To even consider it I'd basically need stumble upon an "almost what I need" full tutorial from install-the-JDK all the way to publish-module-to-marketplace.

The Ignition SDK opens up Ignition to all kinds of user/organization extensions and customizations. This course will introduce you to the basic foundations of Ignition SDK module development, from ground zero upward.

I have been thinking about this diagram a lot, how to improve some of the shortcomings to the large projects we have... We have projects with hundreds of views so any project design implementation choices we made early on are coming home to roost. In the diagram

where would you put the actual projects that put all the inherited resources together (i.e. those that don't contain reusable views, but the projects in which the reusable, global views actually get used)? I'm assuming that's what ui1- ui4 are. If that's the case, it seems to me that ui1 then wouldn't be able to use scripts in the gsp project because bg_common is a sibling to ui_common, not a parent. The overall idea here is still valuable and much better than what we have now - again, this is for a large project with probably close to a 1000 views and the accompanying scripts, styles and so on (by project, I almost mean product, not Ignition project - we do have 2 level inheritance set up and many different Ignition projects to split up the functionality; it just got sloppy after a few years and many developers). I will probably create a new thread to aggregate all the information I can, but wanted to get your input on this in the meantime.

Gateway Church is a family of believers in Upstate New York who are excited about Jesus Christ, the living God! Together, we believe that God is not a faraway creator, but an ever-present comforter and friend who seeks to move in our lives.

APOS Live Data Gateway solution expands, simplifies and unifies your data connectivity for SAP Analytics Cloud. This middleware platform provides virtualized data connectivity which enables live data connectivity to a vast range of non-SAP data sources. With Live Data Gateway, you can leverage the unique benefits of live data connections in SAP Analytics Cloud including your valuable non-SAP data.

In today's data landscapes it is critical that there is strong processing performance for large and growing data environments including Cloud and Big Data platforms. Live Data Gateway has been designed to thrive with such scenarios. See how the APOS Live Data Gateway performs with large data sets in Snowflake (288 billion rows - 10TB data set) and Google BigQuery (196 million rows)

3a8082e126