Local setup of OIH - Can't create components and OIH user is redirected to auth login page when clicking on Hub & Spoke menu option in Web-UI

Describe the bug While following the User Tutorial following bugs appeared

1. After configuring a component in JSON format in the Web-UI service, you click save and you return to the Web-UI. Then you should see listed configured components, but nothing is appearing, also the component count equals zero.
2. When clicking on Hub & Spoke OIH the Web-UI immediately redirects to login page http://web-ui.localoih.com/auth

To Reproduce

I followed the steps from the official Local Setup tutorial from the OpenIntegrationHub Homepage After that via postman I created the admin token, the service account and the persistent service token. Then I replaced the placeholder in the SharedSecret.yaml with the base64 encoded persistent service token. Then I applied the Secret Service and the rest of the services to the kubernetes node. Then I continued with the User Tutorial

Steps to reproduce the behavior:

1. Setup minikube v1.7.3 and kubernetes v1.17.0
2. Start minikube minikube start --vm-driver=virtualbox --memory 16384 --cpus 4
3. kubectl apply -f ./1-Platform
4. Windows host rule setup
5. kubectl apply -f ./2-IAM
6. Login as Admin and generate token
7. Create a Service Account
8. Create persistent token
9. Base64 encode the returned token
10. Copy encoded token to SharedSecret.yaml and set entry for iamtoken
11. kubectl apply -f ./3-Secret.
12. kubectl apply -Rf ./4-Services
13. Open Web-UI and login via admin account
14. Do the User Tutorial
15. Click on Components, click on Add button and copy example json connectors, click on save

{
      "distribution":{
         "type":"docker",
         "image":"elasticio/timer:ca9a6fea391ffa8f7c8593bd2a04143212ab63f6"
      },
      "access":"public",
      "name":"Timer",
      "description":"Timer component that periodically triggers flows on a given interval"
}

1. No data / component stored (see provided screenshot). Component count equals zero
2. For component Hub and Spoke: When clicking, I am immediately redirected to http://web-ui.localoih.com/auth

Expected behavior

1. Components should be stored and displayed correctly
2. The service Hub & Spoke should work and display correctly.

Screenshots Configuring component After saving nothing (no component) displayed:

[SvenHoeffler]

@tboehle Alright, I think I got it to work. It should work automatically on a fresh install, but if you’d like to modify your existing installation instead, here’s how to:

1. Download the newest version of the minikube folder.

2. Expose urls to the new services:

• Reconfigure the ingress with the new settings using kubectl apply -f ./1-Platform
• Add new entries to your hosts file, the same way you’ve already done in the first install: your_minikube_ip app-directory.localoih.com, your_minikube_ip skm.localoih.com, your_minikube_ip dispatcher-service.localoih.com. Alternatively, you can also just re-add the whole batch as described on the updated Readme

1. Modify service token and secret:

• Create a new persistent token just like on the first install, but give it an additional permission. The request body should look like:

{
	"accountId": "{PASTE SERVICE ACCOUNT ID HERE}",
        "expiresIn": -1,
        "initiator": "{PASTE SERVICE ACCOUNT ID HERE}",
        "inquirer": "{PASTE SERVICE ACCOUNT ID HERE}"
	"permissions": [
		"all"
		]
}

Usually this would be unsafe, as the “all” permission is very powerful, but on a local installation that shouldn’t be an issue.

• Paste the new token into the secret in your new minikube folder, and apply it with kubectl apply -f ./3-Secret

1. Configure SDF Adapter (this is the most tricky part)

• Open your WebUI and navigate to the Components tab
• Add a new component, with this content:

{
  distribution: {
    type: 'docker',
    image: 'openintegrationhub/sdf-adapter:latest'
  },
  access: 'public',
  name: 'SDF Adapter',
  description: 'SDF adapter for the OIH',
  logo: 'https://raw.githubusercontent.com/openintegrationhub/sdf-adapter/master/Logo.png',
  descriptor: {
    triggers: {
      receiveEvents: {
        main: '/lib/triggers/receiveEvents.js',
        title: 'Receives an event from OIH',
        description: 'Receives an event from the dispatcher service of the Open Integration Hub'
      }
    },
    actions: {
      sendMessageToOih: {
        main: './lib/actions/sendMessageToOih.js',
        description: 'Sends a message to Open Integration Hub',
        title: 'Send message to OIH'
      },
      processRecordUid: {
        main: '/lib/actions/processRecordId.js',
        title: 'Send recordUid to OIH',
        description: 'Sends a application recordUid to Open Integration Hub'
      }
    }
  }
}

• Once successful, select the new component, click Update, find the field id and copy its value.
• In your downloaded minikube folder, navigate to /4-Services/dispatcher-service/k8s and open the file deployment.yaml.
• Find the part looking like this:

              - name: "SDF_ID"
              value: "ReplaceMe"

• Replace the ReplaceMe with the id value you just copied. Make sure you don’t accidentally change anything about the indentations of the file

1. Update or create all affected services using kubectl apply -Rf ./4-Services

And that should hopefully do the trick, allowing you to access the App Directory and Hub&Spoke menus in the WebUi to experiment with them. If any issues persist, please do feel free to let us know!

[SvenHoeffler]

@tboehle You’re correct that fetching specific data on demand is not currently part of the usual integration flow concept. So far, they’re one-directional: The source-adapter fetches data based on information it only knows locally (usually anything that updated since the last fetch) and pushes that data down the line, where it is eventually pushed to the target application.

However, the Data Hub might offer an approach for a use-case like this. As you may already know, the Data Hub can optionally be used as a central data store for flows. So you could have an arbitrary number of source applications feeding data into the Data Hub for storage, which could then be fetched on demand by a target application via the Data Hub’s REST API. The logic for when and what to fetch would have to be implemented outside the OIH, however.