-
Epic
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
Better outputs provided by SBO
-
False
-
None
-
False
-
Not Selected
-
To Do
-
QE Needed, Docs Needed, TE Needed, Customer Facing, PX Needed
Problem
When a developer is doing the action of binding a service to an application, it might be that the injected data will not be triggered by the application. It could be that the data is not expected with the same "naming" for the key, it could be that the application is expecting the data in a differently named file... or other reasons.
The problem is that, how a developer is going to understand this error and how to know "exactly" what the binding did and how to leverage the data.
Another problems is that:
- When doing a binding from ODC, developer have no information about what it is really doing
- When "ODO bind", there are not outputs that are providing guidance to the developer.
Description
In order to simplify and improve the developer experience in tools that are leveraging SBO we should look at the different outcomes a developer would be interested in:
- Where are the binding data injected?
- What are the keys that I can leverage?
- If I'm in a java or node application, is there an easy way for me to leverage those in my app's source code?
Those information should be provided along with the status of the Service Binding, so that when tools are catching that the service binding has been properly setup, the tools will be able to get those information and provide them to the end-user.
As those information are relevant until the Service Binding exist and is alive, we should make sure that there is a way to pull those information in a convenient way to the end user.
Why is that important
Improve experience when doing a binding and better enabling the developer to leverage it.
Expected work as part of this epic
- Define clear messages outcomes of binding action
- Work with tools to provide a format that they can leverage
- Work with tools to make sure that the message are getting displayed to the end-user
Acceptance Criteria
TBD
Design Notes:
TBD