Technical Extensions

[dongniwang]

Add Technical Extensions Management to Global Settings page. Settings -> Technical Extensions Users can't edit technical extensions in UI. Technical Extensions show up in Steps.

• Create
  • Name & Description
• View
• Delete
• List

[amysueg]

From F2F whiteboard sessions

[lburgazzoli]

@dongniwang user can't create a new technical extension in the UI, it can only be uploaded as an archive which includes a metadata providing name and description for the extension and the related steps.

[dongniwang]

@lburgazzoli

Thanks for the clarification. Yes! I'm aware of that. They can't create in the ipaas UI, but they do have the ability to Add New, which means that they can upload a file.

Do you have any updates on what kind of information the metadata would include?

[lburgazzoli]

A basic discussion about the meta data format/content is here https://github.com/syndesisio/syndesis-project/issues/120. It is not yet finalized so there maybe some small changes but we are trying to make it a similar as a connector definition as possible where each action/extensionPoint would represent a step.

[rhuss]

@dongniwang is this issue you referred to in the standup meeting ?

@nicolaferraro (sorry, @lburgazzoli is on PTO the next three days ;-) could you please extract short summary from https://github.com/syndesisio/syndesis-project/issues/120 with meta-data actually is included, best as some kind of bullet list ? would be awesome and would help UX quite a bit to design the extension overview page after an upload.

[nicolaferraro]

@dongniwang, @rhuss you can find more info about the metadata in the doc proposal.

Here's a overview of the data contained in the metadata (the proposal is in evolution):

• extension id (consistent across upgrades)
• kind (="extension" for now)
• version
• status ("draft" when uploaded)
• name
• description
• icon
• tags
• list of maven dependencies (list of maven gav strings)
• a list of "actions" (or "steps") included in the tech extension, for each one:
  • id
  • name
  • description
  • action type (="extension" for now)
  • tags
  • input data shape
  • output data shape
  • action descriptor (see doc for details)
  • list of configuration properties of the action

I don't know if @paoloantinori wants to add something to the list

[paoloantinori]

I have just started the activity to produce a json according to the templated in the linked doc. At the moment I'm just following the defined structure without focusing of the semantics of it.

If I find any need for a change I'll update the discussion here.

Since I need it to produce the corresponding json file, I'm creating the corresponding Model java class. If you need it before it's merged it, just ping me.

[dongniwang]

@nicolaferraro @paoloantinori thanks so much for the information!

I'm assuming we're not showing all the information contained in the metadata in the UI, right? So what users would see in the UI are:

• tech extension name
• tech extension description
• icon (not sure if we need an icon for tech extension?)
• tags (I'm not sure what kind of tags we're talking about here?)
• a list of "steps"
  • step name
  • step description

Do we need to surface the extension id?

[paoloantinori]

Tags are just an unbound taxonomy of labels.

Imagine any utilisation from "experimental" to "marketing"...

The usual example to explain arbitrary tags are Gmail labels.

Regarding name vs. id:

Id is expected to be code generated, from the model point of view. An import of an external extension definition is expected to discard an eventual id field to generate a new one.

And currently we don't have any uniqueness constraint on the name field, so if you omit the id, the UI could end up showing 2 entries apparently carrying the same logical name.

Sent from mobile

On 31 Oct 2017 2:55 p.m., "Dongni (Iris) Wang" notifications@github.com wrote:

@nicolaferraro https://github.com/nicolaferraro @paoloantinori https://github.com/paoloantinori thanks so much for the information!

I'm assuming we're not showing all the information contained in the metadata in the UI, right? So what users would see in the UI are:

• tech extension name
• tech extension description
• icon (not sure if we need an icon for tech extension?)
• tags (I'm not sure what kind of tags we're talking about here?)
• a list of "steps"
  • step name
  • step description

Do we need to surface the extension id?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/syndesisio/syndesis-ux/issues/44#issuecomment-340769405, or mute the thread https://github.com/notifications/unsubscribe-auth/ABcz2sW-_PiLZ4hYC7gkoO40zkh2a6ZOks5sxybPgaJpZM4PoxtE .

[nicolaferraro]

Thanks @paoloantinori. It can be useful to show the extension logical id (maybe aside from the main set of information) also because citizen users can use it to uniquely identify a extension when talking with expert developers.

I forgot an important piece here. It's not part of the metadata, but after the extension upload, the backend does a validation of the tech extension. I think the UI should be able to display the following information:

• List of validation errors: errors will prevent the user to continue with extension installation
• List of warnings: warnings can be ignored by the user that can continue with installation

This is a proposal, we can discuss about it. Btw, in general, the provided file may have illegal data, wrong dependencies, or it may be not compatible with a existing extension in case of upgrade. The extension cannot be installed when a error is present.

The warnings may be useful to display information such as (in case of upgrade): "The extension is used by the following integrations ..... . You will need to upgrade them manually". Or any other warning messages for the citizen user that doesn't prevent him to continue.

[dongniwang]

Close via https://github.com/syndesisio/syndesis-ux/pull/50