Accessing java API within an own module from perspectives

Module Development
, ,
1

Hi everyone,

I have a question regarding an own Ignition Module and accessing it from a script in perspectives.

We want to integrate a more complex system that is available to us via a SOAP interface. Data that needs to be retrieved here may also need to be combined. Basically, we want to build a presentation layer in Ignition. Our plan:

  • We use the SDK and implement the backend as an Ignition Module. A service API with the methods will be provided for access. There will be about 50 methods on the business Interface.

  • We use Ignition's perspectives to represent the data. Scripts access the API (Java classes) from the backend module.

I'm currently working on a proof of concept.

My specific questions:

  1. Which hook is sufficient for the module? Does it need to have a Designer and Client hook? For me, only the Gateway hook and Context would make sense.

  2. How do the Perspectives access the Java Service API?

  3. Can Jython directly access the classes? What needs to be done to ensure that the service in its own module is in the correct classpath? The idea in jython is:

from com.mycompany.mymodule.api import MyBusinessService is this possible? I don't get this working.

  1. Does a script module need to be added for each service class in Java using manager.addScriptModule()? This is the only way I was able to access the API on Module.

  2. There is also this annotation: ScriptFunction Is this annotation needed, or is it just a "hint".

I'm happy to hear some best practices

Regards
Chris

2

  • Gateway hook is sufficient for Perspective.

  • Perspective would access your module's features through custom expression functions and/or custom system.something.* scripting functions. It would not access java's service API directly.

  • No, jython will not be able to directly load java classes from 3rd party modules. But you can expose specific classes under system.something.* using public static final fields in the script class you register:

static public final Class<?> SomeClassName = SomeClassName.class;

  • You can add many of your module's classes using the static field method. Such will have no editor hints.

  • Generally, where access to your module involves a common sequence of operations, a scripting function is usually supplied to minimized the jython/java transitions. Such functions definitely should be annotated. Ideally, they should use the keyword-argument compatible method signature:

static public PyObject someFunction(PyObject[] args, String[] keywords)
1 Like
3

Fixed in 8.3.0 :slight_smile:

2 Likes
4

Hi @pturmel @PGriffith ,

thank you very much for your quick response. I already stripped down the module and remove unused hooks. The developer hints are important, but does not have the highest priority at the moment. Thanks for the version hint.

In my own module I added a 3rd party java lib and noticed some transitive dependencies was missing on the modl file. Is there an official way how to handle 3rd party libs on modules?

Thanks

5

What build tool are you using and how are you building the module? These should get included automatically unless they are optional/runtime dependencies.

6

Hi @Kevin.Herron,

the module is build with the maven archetype. Additionally, I added an own maven module including my services. On this module there is e.g. a jersey-client defined, which provides a very comfortable way to interact with REST APIs including (de)-serialization.

This maven module is also assigned to a scope in the build module and I can see the jersey-client jar is packaged in the modl file correctly. But this is not enough, because there are transitive dependencies. It seems the modl build mojo does not include transitive dependencies? Is this assumption correct?
E.g. the packaged service module as fat-jar works fine.

I also tried to define my services module as fat-jar (including all dependencies) in the build. Tried this with the maven classifier mechanism.

Thanks a lot for some hints in advance.

7

I think you'll need to share some concrete details and/or your actual build files.

I verified the transitive dependencies are collected and included in the module by adding this dependency to the OPC UA device example project and then building and inspecting the module:

        <dependency>
            <groupId>org.eclipse.milo</groupId>
            <artifactId>sdk-client</artifactId>
            <version>0.6.8</version>
        </dependency>

Module contents:

image
image611×825 61.6 KB

8

I found the issue. You are right, the transitive dependencies are bundled.
I forgot about to change the version of the ignition-maven-plugin to version 1.2.0 after creating it with the archetype.

I just checked, because I would update the version and create a PR. But there is already one: Upgraded Archetype Dependency Versions by cmwarre · Pull Request #7 · inductiveautomation/ignition-sdk-archetypes · GitHub

Thanks a lot for testing it.