Skip to content

Commit aab797d

Browse files
wommel0wommel0
committed
Initial commit
1 parent 54fb49d commit aab797d

File tree

160 files changed

+7162
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

160 files changed

+7162
-0
lines changed

‎.github/workflows/ci.yml

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
name: ci
2+
on:
3+
push:
4+
branches:
5+
- master
6+
- main
7+
permissions:
8+
contents: write
9+
jobs:
10+
deploy:
11+
runs-on: ubuntu-latest
12+
steps:
13+
- uses: actions/checkout@v4
14+
- name: Configure Git Credentials
15+
run: |
16+
git config user.name github-actions[bot]
17+
git config user.email 41898282+github-actions[bot]@users.noreply.github.com
18+
- uses: actions/setup-python@v5
19+
with:
20+
python-version: 3.x
21+
- run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV
22+
- uses: actions/cache@v4
23+
with:
24+
key: mkdocs-material-${{ env.cache_id }}
25+
path: .cache
26+
restore-keys: |
27+
mkdocs-material-
28+
- run: pip install mkdocs-material
29+
- run: mkdocs gh-deploy --force

‎README.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,4 @@
11
# llm_coder
22
LLM Coder package
3+
4+
Still trying out stuff.

‎docs/Claude 3.5 Haiku/FUGR/Z_LLM_CLIENT/TABLEFRAME_Z_LLM_CLIENT.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
---
2+
title: TABLEFRAME_Z_LLM_CLIENT
3+
type: FUNC
4+
parent_object: Z_LLM_CLIENT
5+
parent_type: FUGR
6+
---
7+
8+
# Function Module TABLEFRAME_Z_LLM_CLIENT
9+
10+
AI Generated documentation.
11+
## Overview
12+
The function module `TABLEFRAME_Z_LLM_CLIENT` is a standard SAP view maintenance generator function designed to handle table frame operations for a custom client-related table. It appears to be an automatically generated function module used for managing view maintenance activities in an SAP ABAP system.
13+
14+
## Dependencies
15+
- Standard SAP View Maintenance Framework
16+
- Performs operations on predefined tables:
17+
- `X_HEADER`
18+
- `X_NAMTAB`
19+
- `DBA_SELLIST`
20+
- `DPL_SELLIST`
21+
- `EXCL_CUA_FUNCT`
22+
23+
## Details
24+
The function module utilizes the `PERFORM TABLEFRAME` statement, which is a standard SAP mechanism for view maintenance. It passes several key parameters:
25+
26+
```mermaid
27+
graph TD
28+
A[TABLEFRAME Function] --> B[X_HEADER]
29+
A --> C[X_NAMTAB]
30+
A --> D[DBA_SELLIST]
31+
A --> E[DPL_SELLIST]
32+
A --> F[EXCL_CUA_FUNCT]
33+
A --> G{Additional Parameters}
34+
G --> H[CORR_NUMBER]
35+
G --> I[VIEW_ACTION]
36+
G --> J[VIEW_NAME]
37+
```
38+
39+
Key characteristics:
40+
- Automatically generated on 02.01.2025
41+
- Part of view maintenance generator version #001407#
42+
- Handles table frame operations for a custom table related to LLM (likely Large Language Model) client configuration
43+
- Provides a standardized interface for view-based table maintenance in SAP
44+
45+
The function is designed to be a generic handler for view-related operations, likely supporting standard CRUD (Create, Read, Update, Delete) actions on the associated table.
46+

‎docs/Claude 3.5 Haiku/FUGR/Z_LLM_CLIENT/TABLEPROC_Z_LLM_CLIENT.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
---
2+
title: TABLEPROC_Z_LLM_CLIENT
3+
type: FUNC
4+
parent_object: Z_LLM_CLIENT
5+
parent_type: FUGR
6+
---
7+
8+
# Function Module TABLEPROC_Z_LLM_CLIENT
9+
10+
AI Generated documentation.
11+
## Overview
12+
The function module `TABLEPROC_Z_LLM_CLIENT` appears to be a generic table processing function generated on 02.01.2025. Its primary purpose seems to be executing a standard table procedure through the `TABLEPROC` perform, which suggests it is likely part of a generated view maintenance or table management framework.
13+
14+
## Dependencies
15+
No explicit dependencies are visible from the provided source code snippet. The function relies on a perform routine `TABLEPROC`, which is likely defined in a common include or standard SAP library.
16+
17+
## Details
18+
The function module is extremely minimal, containing only a single perform call to `TABLEPROC`. This suggests it is:
19+
- Likely part of an automated code generation process
20+
- Probably a wrapper or standardized entry point for table-related operations
21+
- Potentially used in view maintenance or data management scenarios for a client-related table (Z_LLM_CLIENT)
22+
23+
The generation timestamp and version number (#001407#) indicate this is a systematically created function module, possibly generated by a view maintenance tool or custom development framework in SAP.
24+
25+
```mermaid
26+
flowchart TD
27+
A[TABLEPROC_Z_LLM_CLIENT Function Module] --> B[TABLEPROC Perform]
28+
B --> C{Table Processing Logic}
29+
```
30+
31+
Without additional context from the common includes, the exact nature of the table processing cannot be definitively determined, but it appears to be a standardized approach to handling table-related operations.
32+

‎docs/Claude 3.5 Haiku/ZCL_LLM_AUTH_DISABLED_CLAS.md

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
---
2+
title: ZCL_LLM_AUTH_DISABLED
3+
type: CLAS
4+
parent_object: ZLLM_CLIENT
5+
parent_type: DEVC
6+
---
7+
8+
# Class ZCL_LLM_AUTH_DISABLED
9+
10+
AI Generated documentation.
11+
## Overview
12+
The `zcl_llm_auth_disabled` class is an implementation of the `zif_llm_auth` interface that provides a permissive authorization mechanism. This class is designed to disable or bypass authorization checks for various cryptographic and client-related operations. It serves as a default or test implementation where no strict authorization restrictions are enforced.
13+
14+
The class implements four key authorization methods:
15+
1. `check_decrypt()`: Authorization check for decryption operations
16+
2. `check_encrypt()`: Authorization check for encryption operations
17+
3. `check_get_client()`: Authorization check for client retrieval
18+
4. `check_provider_maintenance()`: Authorization check for provider maintenance tasks
19+
20+
Each method is intentionally left empty, effectively allowing all operations without raising authorization exceptions.
21+
22+
## Dependencies
23+
- Interface: `zif_llm_auth`
24+
- Potential Exception: `ZCX_LLM_AUTHORIZATION` (not raised in this implementation)
25+
26+
## Details
27+
The class represents a "disabled" authorization strategy, which is particularly useful in:
28+
- Testing scenarios
29+
- Development environments
30+
- Situations requiring unrestricted access to cryptographic methods
31+
32+
```mermaid
33+
graph TD
34+
A[zcl_llm_auth_disabled] -->|Implements| B[zif_llm_auth Interface]
35+
A --> C[check_decrypt()]
36+
A --> D[check_encrypt()]
37+
A --> E[check_get_client()]
38+
A --> F[check_provider_maintenance()]
39+
40+
C --> G[No Authorization Restrictions]
41+
D --> G
42+
E --> G
43+
F --> G
44+
```
45+
46+
Key characteristics:
47+
- Provides a "pass-through" authorization mechanism
48+
- Marked as `FINAL` and `PUBLIC`, preventing further inheritance
49+
- Uses `#EC EMPTY_PROCEDURE` to suppress potential code inspector warnings about empty methods
50+
- Intended to be registered in a BADI (Business Add-In) named `ZLLM_DEFAULTS`
51+
52+
The implementation suggests a flexible design where custom authorization logic can be easily plugged in by replacing this default implementation.
53+

‎docs/Claude 3.5 Haiku/ZCL_LLM_CALL_LOGGER_CLAS.md

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
---
2+
title: ZCL_LLM_CALL_LOGGER
3+
type: CLAS
4+
parent_object: ZLLM_CLIENT
5+
parent_type: DEVC
6+
---
7+
8+
# Class ZCL_LLM_CALL_LOGGER
9+
10+
AI Generated documentation.
11+
## Overview
12+
The `zcl_llm_call_logger` is a specialized ABAP class designed to log LLM (Large Language Model) call entries with configurable logging behavior. It implements the `zif_llm_call_logger` interface and provides a mechanism to conditionally log entries based on system settings and user filters.
13+
14+
Key functionalities:
15+
- Conditional logging of LLM call entries
16+
- System-wide logging activation control
17+
- User-specific logging filter
18+
- Automatic configuration during object instantiation
19+
20+
Public Methods:
21+
- `zif_llm_call_logger~add()`: Logs an entry to the `zllm_call_log` table if logging is active
22+
- `constructor()`: Initializes logging configuration by checking system settings
23+
24+
## Dependencies
25+
- Database Table: `zllm_system` (for system configuration)
26+
- Database Table: `zllm_call_log` (for storing log entries)
27+
- Interface: `zif_llm_call_logger`
28+
29+
## Details
30+
The logging mechanism follows a two-stage filtering process:
31+
32+
```mermaid
33+
flowchart TD
34+
A[Constructor] --> B{System Logging Enabled?}
35+
B -->|Yes| C{User Filter Matches?}
36+
B -->|No| D[Logging Inactive]
37+
C -->|Yes| E[Logging Active]
38+
C -->|No| D
39+
```
40+
41+
Logging Configuration Logic:
42+
1. During object creation, the constructor queries the `zllm_system` table
43+
2. Checks if system-wide logging is enabled (`save_calls = abap_true`)
44+
3. Validates user filter:
45+
- Matches current user (`sy-uname`)
46+
- Or allows all users (`call_filter_uname = '*'`)
47+
4. Sets the `active` flag accordingly
48+
49+
When `zif_llm_call_logger~add()` is called:
50+
- Checks the `active` flag
51+
- If active, inserts the entry into `zllm_call_log`
52+
- If inactive, silently returns without logging
53+
54+
This design allows flexible, configurable logging with minimal performance overhead.
55+

‎docs/Claude 3.5 Haiku/ZCL_LLM_CHAT_REQUEST_CLAS.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
---
2+
title: ZCL_LLM_CHAT_REQUEST
3+
type: CLAS
4+
parent_object: ZLLM_CLIENT
5+
parent_type: DEVC
6+
---
7+
8+
# Class ZCL_LLM_CHAT_REQUEST
9+
10+
AI Generated documentation.
11+
## Overview
12+
The `zcl_llm_chat_request` class is an implementation of the `zif_llm_chat_request` interface, designed to manage and manipulate chat requests for Large Language Model (LLM) interactions. It provides a comprehensive set of methods to:
13+
- Add and manage chat messages
14+
- Handle tools and tool results
15+
- Configure structured output
16+
- Manage tool choices
17+
- Retrieve internal request details
18+
19+
Key public methods include:
20+
- `add_message`: Add a single message to the request
21+
- `add_messages`: Add multiple messages at once
22+
- `add_tool`: Add a tool to the request
23+
- `add_tool_result`: Add a tool result message
24+
- `clear_messages`: Remove all messages
25+
- `clear_tools`: Remove all tools
26+
- `set_tool_choice`: Configure tool selection strategy
27+
- `set_structured_output`: Define structured output schema
28+
- `get_internal_request`: Retrieve the full internal request object
29+
30+
## Dependencies
31+
- `zif_llm_client`: Interface for role constants
32+
- `zcl_llm_common`: Utility class for JSON conversion
33+
- `zllm_request`: Custom data type for storing chat request details
34+
35+
## Details
36+
The class uses a central `request` attribute of type `zllm_request` to store and manage all request-related information. It acts as a builder/configuration class for preparing LLM chat requests with flexible options.
37+
38+
```mermaid
39+
classDiagram
40+
class zcl_llm_chat_request {
41+
- request : zllm_request
42+
+ add_message(message)
43+
+ add_tools(tools)
44+
+ set_tool_choice(choice)
45+
+ get_internal_request() : zllm_request
46+
}
47+
class zif_llm_chat_request {
48+
<<interface>>
49+
}
50+
zcl_llm_chat_request ..|> zif_llm_chat_request : implements
51+
```
52+
53+
Key design characteristics:
54+
- Implements a fluent interface for building chat requests
55+
- Supports dynamic addition of messages, tools, and tool results
56+
- Provides methods for configuring advanced LLM request features
57+
- Maintains a flexible internal request structure
58+
- Allows retrieval of the complete configured request object
59+
60+
The class is designed to be used as a configuration builder before sending a request to an LLM client, providing a type-safe and structured approach to preparing chat interactions.
61+

‎docs/Claude 3.5 Haiku/ZCL_LLM_CLIENT_BASE_CLAS.md

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
---
2+
title: ZCL_LLM_CLIENT_BASE
3+
type: CLAS
4+
parent_object: ZLLM_CLIENT
5+
parent_type: DEVC
6+
---
7+
8+
# Class ZCL_LLM_CLIENT_BASE
9+
10+
AI Generated documentation.
11+
## Overview
12+
`zcl_llm_client_base` is an abstract base class for implementing Large Language Model (LLM) clients across different providers. It provides a standardized framework for:
13+
- Creating chat requests
14+
- Handling HTTP communication
15+
- Processing LLM responses
16+
- Managing tool calls and structured outputs
17+
18+
Key public methods:
19+
- `chat()`: Sends a chat request to the LLM provider
20+
- `new_request()`: Creates a new chat request with default configurations
21+
- `get_client()`: Retrieves a provider-specific client implementation
22+
23+
## Dependencies
24+
- `zif_llm_client`: Main client interface
25+
- `zif_llm_http_client_wrapper`: HTTP communication wrapper
26+
- `zif_llm_tool_parser`: Tool parameter parsing
27+
- `zif_llm_statistics`: Statistics tracking
28+
29+
## Details
30+
The class implements a flexible and extensible architecture for LLM interactions with several key design aspects:
31+
32+
```mermaid
33+
classDiagram
34+
class zcl_llm_client_base {
35+
+zif_llm_client~chat()
36+
+zif_llm_client~new_request()
37+
#build_request_json()
38+
#handle_http_response()
39+
#handle_tool_calls()
40+
}
41+
note for zcl_llm_client_base "Abstract base class\nProvides core LLM client functionality"
42+
```
43+
44+
Key architectural patterns:
45+
- Abstract methods for provider-specific implementations
46+
- Standardized response and request handling
47+
- Flexible tool call and structured output processing
48+
- Configurable via client and provider configurations
49+
50+
Request processing flow:
51+
1. Create request via `new_request()`
52+
2. Configure request parameters
53+
3. Call `chat()` method
54+
4. Internal methods handle:
55+
- JSON request building
56+
- HTTP communication
57+
- Response parsing
58+
- Tool call processing
59+
60+
The class supports:
61+
- Multiple LLM providers
62+
- Structured output generation
63+
- Tool call execution
64+
- Detailed usage statistics tracking
65+
66+
Extensibility is achieved through abstract methods like `get_chat_endpoint()`, `set_auth()`, allowing provider-specific implementations while maintaining a consistent interface.
67+

0 commit comments

Comments
 (0)