openintegrationhub: 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

@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!

@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.

@tboehle Ah, I think that’s because you’re sending

{
  "accountId": "{5e68b23f5ea1360011dbf564}",
  "expiresIn": -1,
  "initiator": "{5e68b23f5ea1360011dbf564}",
  "inquirer": "{5e68b23f5ea1360011dbf564}"
}

When instead it should be

{
  "accountId": "5e68b23f5ea1360011dbf564",
  "expiresIn": -1,
  "initiator": "5e68b23f5ea1360011dbf564",
  "inquirer": "5e68b23f5ea1360011dbf564",
	"permissions": [
		"all"
		]
}

The curly braces in the readme are just intended to signify a placeholder, which is… probably not the cleanest way to do that. In practice the string should only contain the id itself and nothing else. I’ll update it to make it less confusing. 😅

As for the IAM Swagger, thanks for catching that, I’ll pass it along!

@tboehle Ah yes, looks like a bit of the documentation got swallowed there somehow. The idea is that you create a viewable webhook using a site like https://webhook.site. This will give you a link to plug into the [ADD WEBHOOK URL HERE] part. After that, any request sent by the OIH should pop up on the webhook.site interface. We’ll see about making that process a bit clearer in the documentation soon.

Progress update on Hub&Spoke: So far I’ve managed to get the Hub&Spok service itself running locally, but its integration with the web-ui is giving me some headaches. But at the very least it will be usable via Postman or something similar. I’ll post again later today or tomorrow with a more detailed how-to.