Conversation
Mainly replaces destination-based approach for App2App with simple pure application.yaml based approach. Also aligned API name between App2App and Binding-based approach. This show-cases how only minor changes are required across the three scenarios: 1. Binding config with URL 2. Binding config with URL and IAS Dependency Name 3. Binding config with custom service binding
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Here's a supportive code review enhanced by AI assistance. These suggestions offer potential improvements and insights to consider, though they're recommendations rather than requirements. You have full control over which feedback to implement based on your project's specific needs and goals. The AI analysis is here to complement your expertise and help streamline your development process.
Model: claude-sonnet-4-20250514 | Prompt Tokens: 4425 | Completion Tokens: 934
| You can find CDS service definition of `sap.capire.flights.data` in file `target/cds/capire/xflight-data/service.cds` resolved during CDS build step. | ||
| The `binding.name` needs to point to the shared identity instance and `options.url` provides the required location of the remote service endpoint. | ||
| Finally, `onBehalfOf: systemUserProvider` specifies that the remote call is invoked on behalf of the technical provider tenant. | ||
| The `binding.name` needs to point to the shared identity instance and `options.url` together with `http.suffix` provides the required location of the remote service endpoint. |
There was a problem hiding this comment.
The phrase "The binding.name needs to point to" uses passive voice. Consider using active voice for better clarity.
Suggestion:
The `binding.name` points to the shared identity instance and `options.url` together with `http.suffix` provides the required location of the remote service endpoint.
| - Identity instances for provider and consumer | ||
| - Configured IAS dependency from consumer to provider | ||
| - Destination with URL pointing to the provider | ||
| - URL pointing to the provider |
There was a problem hiding this comment.
Consider adding a comma after "consumer" for better readability and to separate the list items more clearly.
Suggestion:
- Identity instances for provider and consumer
- Configured IAS dependency from consumer to provider
- URL pointing to the provider
| The remote service can be configured in a very similar way as with [co-located services](#co-located-consumer). | ||
| You only need to add the information about the IAS dependency to be called (`ias-dependency-name`). |
There was a problem hiding this comment.
The sentence structure can be improved for better clarity. Consider breaking it into two sentences or restructuring.
Suggestion:
The remote service can be configured in a very similar way as with [co-located services](#co-located-consumer). You only need to add the information about the IAS dependency to be called (`ias-dependency-name`).
Co-authored-by: René Jeglinsky <rene.jeglinsky@sap.com>
3 participants
Mainly replaces destination-based approach for App2App with simple pure application.yaml based approach. Also aligned API name between App2App and Binding-based approach.
This show-cases how only minor changes are required across the three scenarios: