feat: create more sample code

[OscarDDD]

Context

Closes SAP/ai-sdk-python-backlog#27.

What this PR does and why it is needed

Adds sample code for document_grounding, sap_rpt, prompt_registry, and LangChain modules, and registers all new functions as FastAPI endpoints in server.py. All endpoints can be tested directly via the FastAPI server.

[yamaceay]

@OscarDDD Thanks for the sample codes! Just for my own understanding:

[q] I would like to know whether there is a correct, efficient way to verify whether the sample code works (without trying out visually). Would unit tests be a feasible option to test the behavior of all these code snippets?

Another question is:

[q] Do you think from a security vs. usability perspective it is feasible to have setup - cleanup functions (directly as decorators etc.) which deploy (& later teardown) the required models? The logic could look something like:

If the deployment already exists: Reuse the available deployment and don't teardown later.
If the deployment doesn't exist: Create a temporary deployment for the sample, then teardown after running the sample.

[mwien]

Looks good! Just a few small comments

[mwien]

@OscarDDD Thanks for the sample codes! Just for my own understanding:

[q] I would like to know whether there is a correct, efficient way to verify whether the sample code works (without trying out visually). Would unit tests be a feasible option to test the behavior of all these code snippets?

Another question is:

[q] Do you think from a security vs. usability perspective it is feasible to have setup - cleanup functions (directly as decorators etc.) which deploy (& later teardown) the required models? The logic could look something like:

If the deployment already exists: Reuse the available deployment and don't teardown later. If the deployment doesn't exist: Create a temporary deployment for the sample, then teardown after running the sample.

Re testing:

• the sample code will likely be used for smoke tests later
• good point re unit tests, we could think about adding those (outside of this PR), as far as I can tell the Java SDK has unit tests in the sample code and the JS one doesn't

Re decorators:
Imo the less magic we add, the more transparent the code examples... the code should prepare people to be able to write their own stuff with the SDK and I'd rather avoid everyone copying decorators because they assume that's strictly necessary.

[OscarDDD]

@OscarDDD Thanks for the sample codes! Just for my own understanding:

[q] I would like to know whether there is a correct, efficient way to verify whether the sample code works (without trying out visually). Would unit tests be a feasible option to test the behavior of all these code snippets?

Another question is:

[q] Do you think from a security vs. usability perspective it is feasible to have setup - cleanup functions (directly as decorators etc.) which deploy (& later teardown) the required models? The logic could look something like:

If the deployment already exists: Reuse the available deployment and don't teardown later. If the deployment doesn't exist: Create a temporary deployment for the sample, then teardown after running the sample.

Regarding the unit tests:
I think it's good to have the unit tests. I'm currently following the JavaScript SDK repo as a reference, so tests haven't been added yet.

Regarding the decorators:
I'm considering whether it would make sense to introduce a setup.py or something similar down the line, to allow users to set up everything they need in one step.

[mwien]

lgtm

[yamaceay]

all questions answered