Posts by ncolter

    We do not have a set release date for any of the packages as of yet. However, there are several releases planned for the next few months specifically centering around the OpenDXL Node-RED extension, so you can expect to see updates fairly soon.

    We're excited to provide this new tool to the community, and we're working to get it into your hands as soon as possible!

    When it comes to determining the danger posed by external files, there are a number of reputation providers that have OpenDXL solutions available for community use (many of which can be found under the Threat Detection category.

    As far as hooking up those solutions to tools like Jabber or Lync, an intermediary tool or service hook would need to be created that made use of the above Threat Detection solutions. We encourage community members like yourself with unique requirements to experiment, and feel free to use existing solutions to create new ones that address needs such as these!

    Certificate-based topic authorization configuration settings that have been set on one ePO Server in a Multi-ePO environment will be applied to the entire Multi-ePO fabric, as long as all ePO Extensions and DXL Brokers in the Multi-ePO environment are DXL 4.0 and above.

    It may take up to 24 hours by default for certificate-based topic authorization policy to propagate across the entire Multi-ePO fabric.

    There is an upcoming solution for smoothly integrating DXL services and events with Node-RED. It will allow users to hook up any tool or service to Node-RED and easily send or receive DXL messages.

    In the meantime, the OpenDXL Data Bridge solution is currently available and incorporates some Node-RED functionality.

    The OpenDXL Java Client does not currently have a scheduled release date, unfortunately. Our development team is listening and is definitely aware of the community demand for a Java client that works with OpenDXL - as it is, our current aim is to bring it in scope as soon as possible.

    For a client with a third-party certificate (such as one generated by the steps you referred to in the OpenDXL Python Client Documentation) to be able to connect to a broker in any DXL fabric, that certificate/authority must be imported into ePO and distributed to the DXL brokers on that fabric.

    In a Multi-ePO environment, an ePO server and the brokers on its DXL fabric will not export third party certs to the other ePOs/fabrics. The administrator must perform this action manually in the ePO Server Settings for "DXL Certificates (Third Party)" for any other fabric in the Multi-ePO environment to which the client is expected to be able to connect.

    By design, DXL will only deliver messages to clients that are connected at the time they are published and does not provide a mechanism for storing messages for later use.

    However, it is certainly possible to build a solution that handles the storage itself. In fact, there are upcoming solutions expected in the near future to provide features that will provide at least some degree of this functionality.

    We have contacted the solution developer over this issue, if there is indeed a bug or some other problem (documentation, perhaps) it should be addressed in the near future.

    In the meantime, you can protect against this error by checking the length of the command line arguments supplied to the script to handle the problem gracefully. For example:

    1. if __name__ == "__main__":
    2. fgt = FGT(fgt_ip)
    3. fgt.login(user,pw)
    4. if len(sys.argv) <1:
    5. # ---> Handle the scenario here <---
    6. else:
    7. host = sys.argv[1]

    It looks like you are trying to use an application generated by OpenDXL Bootstrap's application-template generation function, rather than a client based on the client-template. This is apparent for two reasons: the name of your client file is, which is the default name of the client file created by the application template, and this error in your output:

    TypeError: object of type 'DxlClient' has no len()

    This is a result of the difference in the __init__ used for OpenDXL Bootstrap application templates and client templates.

    In the application template, the __init__ for your client will look like this:

    Python: open-dxlbootstrap-python/dxlbootstrap/
    1. def __init__(self, config_dir, app_config_file_name):
    2. """
    3. Constructs the application
    4. :param config_dir: The directory containing the application configuration files
    5. :param app_config_file_name: The name of the application-specific configuration file
    6. """

    In the client template, it will look like this:

    Python: opendxl-bootstrap-python/dxlbootstrap/
    1. def __init__(self, dxl_client):
    2. """
    3. Constructor parameters:
    4. :param dxl_client: The DXL client to use for communication with the fabric
    5. """

    As you can see, the constructor in the application template does not take in a DxlClient as an argument, and is instead attempting to use the DxlClient you passed it as a file path.

    The Fix:
    The simplest way to fix this issue would be to generate a new client template using the instructions found here: OpenDXL Bootstrap Tutorial Part 4: Create Client Wrapper.

    When running the distribution script generated by OpenDXL Bootstrap, the Python Wheel library is required for the script to be able to create a .whl package. You can check if you have the Wheel library installed by entering > pip show wheel .

    If wheel is already installed, you will see an output similar to this:

    1. c:\Test>pip show wheel
    2. Name: wheel
    3. Version: 0.30.0
    4. Summary: A built-package format for Python.
    5. Home-page:
    6. Author: Alex GrA¶nholm
    7. Author-email:
    8. License: MIT
    9. Location: c:\python27\lib\site-packages
    10. Requires:

    If wheel is not installed, you will see a blank response:

    1. c:\Test>pip show wheel
    2. c:\Test>

    To install the Wheel library, simply use > pip install wheel from the command line.

    It is correct that calling dxlclient.client.DxlClient.add_event_callback() with subscribe_to_topic set to True or leaving it to the default value (also True) will automatically subscribe the DxlClient to the specified topic in the topic parameter. This means that there is no need for your client code to subscribe to the topic as an additional step.

    The sample code for dxlclient.client.DxlClient.subscribe() specifically sets the subscribe_to_topic parameter of add_event_callback() to False to prevent the automatic subscription, and justify the usage of separately calling subscribe() for the code example.

    As for why you would ever want to call subscribe() yourself, that depends on the specific needs of your client.

    • If a client has a reason to set subscribe_to_topic as False, such as avoiding duplicate subscriptions by the same client. For example, using subscribe() to subscribe to a set of topics using a wildcard, and then assigning callbacks to specific topics that would be included in that set later - in that case, it would be better to call add_event_callback() with subscribe_to_topic set to False.
    • If a client calls dxlclient.client.DxlClient.unsubscribe() for a topic, then there may be a need to re-subscribe later.

    Yes, in almost every case outgoing DXL messages should be encoded and incoming messages should be decoded.

    Because the DXL message payload is simply binary data, failing to encode data types that have system dependencies (or other factors) can result in an unexpected format for the data when it is received. By using .encode(), the message sender standardizes the format of the payload so that the receiver(s) can use a matching .decode() call and smoothly interpret the payload as intended.

    To help simplify the process of writing your DXL client code, we recommend using OpenDXL Bootstrap. The bootstrapper includes the MessageUtils class, which provides methods for basic encoding/decoding objects and managing Python dictionaries as JSON payloads.

    clara_kt is correct. In almost all cases, it is simpler and generally safer to use the Python keyword with to avoid having to make the call directly. See the example below:

    1. # Create the DXL client
    2. with DxlClient(config) as dxl_client:
    3. # Connect to the fabric
    4. dxl_client.connect()
    5. # Your code here
    6. # End of script, no need to call .destroy()