How can I validate xsd using apache camel?

 <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:camel="http://camel.apache.org/schema/blueprint"
       xsi:schemaLocation="
       http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
       http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/spring/camel-blueprint.xsd">

  <camelContext xmlns="http://camel.apache.org/schema/blueprint">
      <route>
          <from uri="file:flights/data-in?noop=false"/>
          <doTry>
              <to uri="validator:file:flights/schema/flight.xsd"/>
              <to uri="file:flights/data-valid"/>
              <doCatch>
                  <exception>org.apache.camel.ValidationException</exception>
                  <to uri="file:flights/data-invalid"/>
              </doCatch>
              <!--
              <doFinally>
                  <to uri="file:test/src/data/finally"/>
              </doFinally>
              -->
          </doTry>
      </route>

  </camelContext>

</blueprint>

Ref: https://stackoverflow.com/questions/28263085/how-can-i-validate-xsd-using-apache-camel

Extract Python from installer file.

 msiexec /a python-3.3.2.msi /qb TARGETDIR=%TARGET%

Build dashbuilder-components for Redhat PAM

Build dashbuilder-components for Redhat PAM

•  Clone Project in https://github.com/jesuino/dashbuilder-components
• Install yarn: npm install -g yarn
  
  
• Init project: npm run init 
  
  
• Build project:  npm run build:prod ( must replace "rm -rf" to  "rimraf -rf" on file package.json in case you build on window mache)
  
  
  
  
  

The ports required for a Kubernetes deployment

 Ref: https://docs.oracle.com/en/operating-systems/olcne/1.1/start/ports.html

Setting up the Firewall Rules

Oracle Linux 7 installs and enables firewalld, by default. The Platform CLI notifies you of any rules that you may need to add during the deployment of the Kubernetes module. The Platform CLI also provides the commands to run to modify your firewall configuration to meet the requirements.

Make sure that all required ports are open. The ports required for a Kubernetes deployment are:

• 2379/tcp: Kubernetes etcd server client API (on master nodes in multi-master deployments)

• 2380/tcp: Kubernetes etcd server client API (on master nodes in multi-master deployments)

• 6443/tcp: Kubernetes API server (master nodes)

• 8090/tcp: Platform Agent (master and worker nodes)

• 8091/tcp: Platform API Server (operator node)

• 8472/udp: Flannel overlay network, VxLAN backend (master and worker nodes)

• 10250/tcp: Kubernetes kubelet API server (master and worker nodes)

• 10251/tcp: Kubernetes kube-scheduler (on master nodes in multi-master deployments)

• 10252/tcp: Kubernetes kube-controller-manager (on master nodes in multi-master deployments)

• 10255/tcp: Kubernetes kubelet API server for read-only access with no authentication (master and worker nodes)

The commands to open the ports and to set up the firewall rules are provided below.

Single Master Firewall Rules

For a single master deployment, the following ports are required to be open in the firewall.

Operator Node

On the operator node, run:

$ sudo firewall-cmd --add-port=8091/tcp --permanent

Restart the firewall for these rules to take effect:

$ sudo systemctl restart firewalld

Worker Nodes

On the Kubernetes worker nodes run:

$ sudo firewall-cmd --zone=trusted --add-interface=cni0 --permanent
$ sudo firewall-cmd --add-port=8090/tcp --permanent
$ sudo firewall-cmd --add-port=10250/tcp --permanent
$ sudo firewall-cmd --add-port=10255/tcp --permanent
$ sudo firewall-cmd --add-port=8472/udp --permanent

Restart the firewall for these rules to take effect:

$ sudo systemctl restart firewalld

Master Nodes

On the Kubernetes master nodes run:

$ sudo firewall-cmd --zone=trusted --add-interface=cni0 --permanent
$ sudo firewall-cmd --add-port=8090/tcp --permanent
$ sudo firewall-cmd --add-port=10250/tcp --permanent
$ sudo firewall-cmd --add-port=10255/tcp --permanent
$ sudo firewall-cmd --add-port=8472/udp --permanent
$ sudo firewall-cmd --add-port=6443/tcp --permanent

Restart the firewall for these rules to take effect:

$ sudo systemctl restart firewalld

Setting up Bind9 as a forwarding DNS server

Ref: https://www.richinfante.com/2020/02/21/bind9-on-my-lan

 I recently installed bind9 on one of my raspberry pi’s to use as a dns server for my lan. Here’s my notes from the setup:

Installing BIND9

sudo apt install bind9 bind9utils bind9-doc

Configuring as a Forwarder

Configuration files for bind(9) are located in the /etc/bind directory. We can edit the named.conf.options file to configure our server as a forwarder.

// This is the local lan acl, configure to your subnet.
acl local-lan {
  localhost;
  192.168.1.0/24;
};

options {
  directory "/var/cache/bind";

  // If there is a firewall between you and nameservers you want
  // to talk to, you may need to fix the firewall to allow multiple
  // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

  // If your ISP provided one or more IP addresses for stable
  // nameservers, you probably want to use them as forwarders.
  // Uncomment the following block, and insert the addresses replacing
  // the all-0's placeholder.

  forwarders {
    1.1.1.1; // Cloudflare
    8.8.8.8; // Google
  };

  allow-query { local-lan; };

  //========================================================================
  // If BIND logs error messages about the root key being expired,
  // you will need to update your keys.  See https://www.isc.org/bind-keys
  //========================================================================
  dnssec-enable no;

  dnssec-validation no;
   


  auth-nxdomain no;    // conform to RFC1035
  listen-on-v6 { any; };

  // Additional config for our usage
  recursion yes;
  querylog yes; // Disable if you want, nice for debugging.
  version "not available"; // Disable for security
};

Developing Custom Components for Dashbuilder

 Dashbuilder is the component of Business Central that allows users to create pages and dashboards. Pages are made of small components that can show data, they are so-called displayers.

By default dashbuilder provides multiple displayers that users can drag to pages, for instance:

Reporting components that can be used in Business Central pages

In Business Central 7.43, we introduced a new way of displaying data by allowing users to create their own custom components that can be based on any modern Javascript library, opening to new possibilities to display business data.

In this article, we will introduce the brand new External Components API and how to use it in Business Central.

External Components API

External components are custom page parts that can be developed in order to consume datasets from Business Central and display data in any way that you want. Users can also configure components using parameters provided by the component itself. Dashbuilder allows users to set these parameters values and send it to the component when it is rendered.

In order to create your first component, the entry point to create components is the file manifest.json, which must be placed in the component root directory. Manifest files must have at least the text parameter called “name”, but other parameters are supported:

• Name: The component name that will be displayed in the component pallet;
• Icon: Icon that will be displayed in the component pallet.
• noData: A flag that indicates that the component does not require a dataset;
• parameters: A list of parameters that the components need to be collected by the user.

The list of parameters supported by the component uses ComponentParameter type, which has the following:

• name: The parameter internal name.
• type: Parameter type. Possible values are text, natural_number, combo, and color. When using combo type you must set comboValues.
• category: The category which the field property will be grouped into;
• defaultValue: The initial value presented to the user;
• label: The label used in the component parameters UI;
• comboValues: A list of text values for combo parameters;
• noData: Special attribute which when true will not consume a dataset.

A complete manifest would look similar to this:

Sample manifest.json file that is used for heatmap component

When users drag the component to the page a wizard shows up, renders a component preview and the properties form according to the properties defined in the manifest:

Heatmap component with its parameters

Building data visualization with external components

After manifest.json is finished you can start building your own dashboards. The entry point is index.html. From the index file, you can link javascript and css resources. In javascript code, we can then listen for messages that will be sent by dashbuilder.

window.addEventListener(“message”, receiveMessage, false);

function receiveMessage(event) {

// consume the message

const params = new Map(event.data.properties);

}

The message sent by dashbuilder contains data of type ExternalComponentMessage and contains only an attribute called properties of type Map<String, Object>. In this object you will find:

• The value for any property you have according to what user set in the UI. To retrieve the value uses the attribute name as the key, for example:

params.get(“svg”)

• A special attribute called dataSet, which is of type ExternalDataSet. This is what you should use to get the data from dashbuilder:

params.get(“dataSet”)

The returned dataset object has the following attributes:

• columns: List of columns which is of ExternalColumn type;
• rows: a two-dimensional array with dataset values.

All the rows values are of string type, to get the actual type you can get the column information and find the actual type: rows[row index][column index]. With the “column index” you can get the column information in columns attribute, a column is represented by ExternalColumn object, which has text attributes name, type, and a complex columnSettings attribute. ColumnSettings holds all the user settings for a specific column, it is represented by object ExternalColumnSettings which has the following attributes:

• columnName: The name set by the user in the UI;
• valueExpression: A javascript expression that should be evaluated over the column value;
• emptyTemplate: The text that should be used when the column value is empty;
• valuePattern: A pattern to format column values. Useful for number.

All column settings are configured by the user when the component is dragged to a page:

Users can have settings for each dataset column

External Components configuration

By default, external components are disabled. You can enable it by setting the system property dashbuilder.components.enable as true.

Dashbuilder looks for components in the directory configured using the system property dashbuilder.components.dir. The default value is /tmp/dashbuilder/components and this directory should not be shared with Dashbuilder Runtime. Your components will live inside this directory

Components directory

Components assets are served by ExternalComponentServlet. In Business Central or in Dashbuilder Runtime you can control cache in web.xml using init-param cache-control.

External components in Dashbuilder Runtime

Recently, we introduced the Dashbuilder Runtime web application and export/import feature. All the components you have configured in Business Central will be packaged with the ZIP file exported from the Data Transfer feature. When imported in Runtime then it will be partitioned by import if you are using multi-mode.

Also notice that Runtime caches all the components assets, this can be changed in dashbuilder-runtime.war/WEB-INF/web.xml.

External component servlet mapping. Never change the url-pattern for external components.

It is also recommended to avoid sharing the components directory between Dashbuilder Runtime and Business Central.

Learning more

There’s no limit to what you can do, or what library you can use! For this reason, we have a growing library of components with some cool external components, like heatmaps, an alternative chart library (Victory Charts), and soon a new Maps component. Check it in Github.

To get started check out the hello_user example, a very simple component, and then simplest_component, which uses all external component library, including a filter feature that is also available on this new API.

Ref: https://medium.com/kie-foundation/developing-custom-components-for-dashbuilder-f6fe9f6e0e64

Redhat Document

https://access.redhat.com/documentation/en-us/red_hat_process_automation_manager/7.9/html/managing_red_hat_process_automation_manager_and_kie_server_settings/building_custom_dashboard_widgets_pages_con

55.5. External components

In Business Central, you can add external components to a page. The components are disabled by default. To enable the external components, change the value of dashbuilder.components.enable system property to true.

The external component location is set and configured with the dashbuilder.components.dir system property. The default value of this system property is /tmp/dashbuilder/components. You must set the component under the components directory with a parent directory, which is used as the component ID. For example, if the component ID is mycomp and the component directory is /tmp/dashbuilder/components, then the component base directory is /tmp/dashbuilder/components/mycomp.

Business Central checks the manifest.json file in the components directory. The manifest.json must contain at least one name text parameter.

Table 55.3. manifest.json file descriptions

Parameter	Description
name	Name of the component displayed under Components section.
icon	Icon of the component displayed under Components section.
noData	A flag that indicates that the component does not require a data set.
parameters	The list of parameters are using ComponentParameter type. Supported parameter types include name, type, category, defaultValue, label, and comboValues.

Sample manifest.json file

{
    "name": "Heat Map Experiment",
    "icon": "fa fa-bell-o",
    "parameters": [
        {
            "name": "svg",
            "type": "text",
            "defaultValue": "",
            "label": "SVG XML",
            "category": "SVG Content"
        },
        {
            "name": "svgUrl",
            "type": "text",
            "defaultValue": "",
            "label": "SVG URL",
            "category": "SVG URL"
        }
        ,
        {
            "name": "ksProcessId",
            "type": "text",
            "defaultValue": "",
            "label": "Process ID",
            "category": "Kie Server"
        }
    ]
}

55.5.1. Creating external components

The following procedure describes how to create and add the external components to a page:

Procedure

1. Set the component under components directory with a parent directory.

   For example, if the component ID is mycomp and the component directory is /tmp/dashbuilder/components, then the component base directory is /tmp/dashbuilder/components/mycomp.

2. Create the manifest.json file in the component directory.
3. Create index.html file with HTML content.
4. In a terminal application, navigate to EAP_HOME/bin.

5. To enable the external components, set the value of dashbuilder.components.enable system property to true:

   $ ~/EAP_HOME/bin/standalone.sh -c standalone-full.xml
   -Ddashbuilder.components.dir={component directory base path} -Ddashbuilder.components.enable=true

6. Start Business Central, go to Menu → Design → Pages.

   External Components is available under Components pane.

7. In the Components pane, expand the External Components and drag the required component types to the canvas.
8. Click Save.