| name | sap-transport-request |
| description | Resolves a modifiable SAP transport request, applying the
way_to_get_transport_request policy from sap-dev-core settings.json.
This is the single entry point that all deploy skills (sap-se11, sap-se38,
sap-se37, sap-se24, sap-se91) call when they need a TR — it centralises the
DEFAULT / ASK / CREATE_NEW flow so callers never have to ask the user
themselves. When a new TR is required, delegates creation to /sap-se01
(GUI mode) or to its built-in RFC creator (CTS_API_CREATE_CHANGE_REQUEST).
Honours rule_of_tr_description for the description text. An unverifiable
or non-modifiable candidate TR is re-prompted per the policy loop —
never silently replaced by a freshly created TR.
Resolves Workbench requests by default, or Customizing requests (E070
TRFUNCTION='W') when called with --type customizing (used by /sap-sm30 and
/sap-pfcg) — Customizing candidates are additionally validated for request
class and client (E070C-CLIENT = the pinned client), and use a separate
sap_dev_customizing_request default so one task can hold a TR of each type.
Prerequisites: SAP profile saved via /sap-login (RFC password required).
SAP NCo 3.1 (32-bit, .NET 4.0) in GAC for RFC paths; active SAP GUI session
(use /sap-login first) is additionally required when way_to_get_transport_request=CREATE_NEW
delegates creation to /sap-se01 (GUI).
|
| argument-hint | [transport-request-number] [--type workbench|customizing] [OBJECT_TYPE=<...>] [OBJECT_DESCRIPTION=<...>] |
SAP Transport Request Skill
You resolve a modifiable SAP transport request for the caller, applying the
way_to_get_transport_request policy from sap-dev-core settings.json.
This skill is the single TR-resolution entry point that all deploy skills
must use; they MUST NOT prompt the user for a TR or call /sap-se01
themselves.
Task: $ARGUMENTS
Shared Resources
| File | Purpose |
|---|
<SAP_DEV_CORE_SHARED_DIR>/rules/safety_policy.md | Rule 0 (highest priority) — environment guard; enforced by the create step via sap_safety_gate.ps1 |
<SAP_DEV_CORE_SHARED_DIR>/rules/skill_operating_rules.md | Mandatory operating rules (no SQL writes on standard tables; no unsolicited deploys) |
<SAP_DEV_CORE_SHARED_DIR>/rules/tr_resolution.md | Defines way_to_get_transport_request, rule_of_tr_description, the description placeholders, and the 60-char compression rules. This skill IS the implementation of that rule. |
<SAP_DEV_CORE_SHARED_DIR>/rules/language_independence_rules.md | GUI-scripting language independence — this skill delegates to GUI-driving /sap-se01 for new-TR creation, which must observe the rule |
Step 0 — Resolve Work Directory
Resolve work_dir via the env-aware helper — do NOT take work_dir from a direct settings.json read (that ignores the SAPDEV_AI_WORK_DIR env var and userconfig.json). Use the WORK_DIR= value printed by:
powershell -NoProfile -ExecutionPolicy Bypass -Command ". '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_settings_lib.ps1'; . '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('WORK_DIR=' + (Get-SapWorkDir)); Write-Output ('RUN_TEMP=' + (Get-SapRunTemp))"
The settings note below still applies to the OTHER keys.
Settings reads/writes follow shared/rules/settings_lookup.md — merge per-key on the .value field (env var → settings.local.json → userconfig.json → settings.json); non-per-connection writes go to userconfig.json. Resolve sap-dev-core paths: 2 levels up from <SKILL_DIR> to the plugin root, then settings.json and (if present) settings.local.json.
Per-connection keys (Phase 4.4): way_to_get_transport_request and sap_dev_transport_request are SAP-system-specific. Per settings_lookup.md § Per-connection exception, read them from connections.json[pinned-profile].dev_defaults FIRST (resolve the pin via {work_dir}\runtime\session_registry.json ai_sessions[<id>]); only fall back to the two-file merge when dev_defaults is empty. Skipping this step is what causes the silent cross-system contamination Phase 4.3 was meant to fix.
| Setting | Default if blank |
|---|
work_dir | C:\sap_dev_work |
Set {WORK_TEMP} = {work_dir}\temp
Ensure the temp directory exists:
cmd /c if not exist "{WORK_TEMP}" mkdir "{WORK_TEMP}"
Set {RUN_TEMP} = the RUN_TEMP= value printed above — a fresh per-run scratch
directory {work_dir}\temp\run_<id>, already created by Get-SapRunTemp.
Resolve it once here and reuse it; write this skill's OWN scratch (the
generated sap_tr_run.* and the sap_tr_run.json log-state file) under
{RUN_TEMP} so concurrent TR resolutions never collide on fixed names. When this
skill calls /sap-se16n to read E070, it passes its own
{RUN_TEMP}\se16n_E070.txt as the explicit output path so the producer
(se16n) and this consumer agree on the same per-run location (se16n otherwise
writes to ITS own run dir, which this skill cannot read). {WORK_TEMP} (base) is
kept only for the Step-0 definition above.
Step 0.5 — Start Logging
Start a structured log run. State file: {RUN_TEMP}\sap_tr_run.json. Best-effort. Honours SAPDEV_PARENT_RUN_ID env var so parent skill calls can be linked.
powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action start -StateFile "{RUN_TEMP}\sap_tr_run.json" -Skill sap-transport-request -ParamsJson "{}"
Step 1 — Parse Arguments and Read Policy Settings
Parse $ARGUMENTS:
| Token | Meaning |
|---|
A <SID>K<digits> token | Caller-supplied TR number override (rare; DEFAULT/ASK policies still apply on top) |
--type workbench|customizing | Request class to resolve/create. Default workbench (E070 TRFUNCTION='K'). customizing (aliases cust, W) resolves a Customizing request (TRFUNCTION='W') — see the Request type note below. |
OBJECT_TYPE=<...> | Object type the caller is deploying (REPORT, TABLE, FM, CLASS, MSGCLASS, …). Forwarded to /sap-se01 for description rendering. |
OBJECT_DESCRIPTION=<...> | Object name being deployed. Forwarded to /sap-se01. |
Read from the merged sap-dev-core userConfig (per shared/rules/settings_lookup.md — settings.local.json overrides settings.json per-key on the .value field):
| Setting | Default if blank/unknown |
|---|
way_to_get_transport_request | DEFAULT |
sap_dev_transport_request | (blank) |
sap_dev_customizing_request | (blank) — used instead of sap_dev_transport_request when --type customizing |
sap_dev_mode | GUI |
Validate way_to_get_transport_request. Allowed: DEFAULT, ASK,
CREATE_NEW. Anything else → fall back to DEFAULT and warn the user.
Request type (--type) — Workbench (default) vs Customizing
Default workbench. When --type customizing (aliases cust, W) is passed,
this run targets a Customizing request and the steps below change
consistently — workbench mode is unchanged (backward-compatible default):
- Default/persist key is
sap_dev_customizing_request (a separate task
default), NOT sap_dev_transport_request, so one task can hold one TR of each
type at once. Wherever Steps 1a / 4 say sap_dev_transport_request, read and
write sap_dev_customizing_request instead.
- Validation (Step 1b) additionally requires the candidate's
TRFUNCTION = 'W' AND E070C-CLIENT = the pinned client. A wrong request
class (a Workbench K request) or a foreign client is treated exactly like
"not modifiable" → re-prompt per the policy loop, never silently replaced.
- Creation passes the type through: GUI Create Path →
/sap-se01 create C;
RFC/BDC Create Path → the PS1 -RequestType W (CATEGORY=W).
TRFUNCTION codes: K = Workbench, W = Customizing (E070; verified on
S/4HANA 1909 + ECC 6). E070C (fields TRKORR, CLIENT, TARCLIENT, …) carries a
Customizing request's source client — identical layout on both releases.
Step 1a — Apply the way_to_get_transport_request Policy
Pick a candidate TR per the table below, then proceed to Step 1b to verify
it (or jump straight to the Create Path below if the policy demands a new
TR).
DEFAULT
- Candidate =
$ARGUMENTS TR if supplied, else sap_dev_transport_request.
- If candidate is blank → ask the user:
"No default transport request is set. Provide a modifiable TR number, or
type new to create one."
- User supplies TR → candidate = that TR.
- User types
new → skip to Create Path.
- Verify candidate (Step 1b — mode-aware). If not modifiable, repeat the prompt above.
- On success, persist the resolved TR to
sap_dev_transport_request as a
SESSION-scoped task default — so future DEFAULT calls in THIS conversation
reuse it WITHOUT clobbering other conversations on the same connection. Run
<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_dev_default.ps1 -Action set -Key sap_dev_transport_request -Value <TR> (Session is its default), or
Set-SapUserSetting -Key sap_dev_transport_request -Value <TR> -Scope Session.
Do NOT use /update-config (that writes the global layer, shared across
conversations and systems). See shared/rules/tr_resolution.md §4.
ASK
- Ignore
sap_dev_transport_request.
- Ask the user:
"Which transport request should I use? (TR number, or new to create one)"
- TR number → candidate = that TR.
new → Create Path.
- Verify candidate (Step 1b — mode-aware). If not modifiable, repeat.
- After success, ask once:
"Save <TR> as the default for future requests? (y/N)"
- On
y → persist to sap_dev_transport_request.
CREATE_NEW
- Do NOT read
sap_dev_transport_request. Do NOT ask.
- Go straight to Create Path.
- Do NOT persist the new TR.
Create Path
Rule 0 first (safety_policy.md; TR creation only — resolving/verifying an existing TR is
read-only and ungated; when the calling deploy skill already passed its own Step 0.6 this is a
fast ALLOW re-check):
powershell -NoProfile -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_safety_gate.ps1" -Action assert -Skill sap-transport-request —
SAFETY: ALLOW (0) proceed; TYPED_CONFIRM_REQUIRED (3) -> the operator types the shown
PROD <SID>/<CLIENT> token, re-run with -ConfirmationText '<their verbatim answer>', proceed only
on ALLOW_CONFIRMED; REFUSED class=<C> (1) / ERROR (2) -> STOP, end FAILED with
-ErrorClass <C>, relay the remediation lines — never bypass or work around it manually.
The Create Path is a branching gate. Pick exactly ONE branch based on
sap_dev_mode, execute it end-to-end, then return the resolved TR to the
caller. Do NOT fall through to Steps 2-4 from the GUI branch.
GUI branch (when sap_dev_mode = GUI, the default)
- Invoke
/sap-se01 create <TYPE> — <TYPE> = W for --type workbench
(default) or C for --type customizing — plus the forwarded OBJECT_TYPE=
and OBJECT_DESCRIPTION= arguments. /sap-se01 honours
rule_of_tr_description for the text and maps C to the SE01 Customizing
radio (radKO042-REQ_CUST_W).
- Capture the new TR number from
/sap-se01's output (RESULT_TR: line).
- Apply the persistence policy from Step 1a (
DEFAULT saves automatically;
ASK asks once; CREATE_NEW does NOT save).
- STOP — return the TR to the caller. Skip Steps 2-4 below entirely.
Steps 2-4 are for the verification path (existing TR check) and the
RFC/BDC create branch only; running them in GUI mode would either
pointlessly RFC-verify a TR
/sap-se01 already verified, or worse,
accidentally create a SECOND TR via the RFC creator.
RFC / BDC branch (when sap_dev_mode ∈ {RFC, BDC})
- Build the description locally using the same
rule_of_tr_description
algorithm (see <SAP_DEV_CORE_SHARED_DIR>/rules/tr_resolution.md §3).
- Fall through to Steps 2-4 below — they use the RFC
CTS_API_CREATE_CHANGE_REQUEST path. Pass %%TRANSPORT_REQUEST%% empty
and %%SAP_DEV_MODE%% set to RFC (or BDC) so the PS1's guardrail
permits creation, and pass the description built in item 1 via the
-Description argument at execution (Step 3) — the PS1 falls back to a
generic literal only when -Description arrives empty. For --type customizing, also pass -RequestType W so the RFC creator makes a
Customizing request (CATEGORY=W); workbench omits it (PS1 defaults K).
Mid-session policy change
If during a session the user explicitly says e.g. "switch to ask mode",
"always create new from now on", or "use the default TR every time", update
way_to_get_transport_request immediately and follow the new policy for the
rest of the session. Because it applies to THIS conversation only, persist it
SESSION-scoped (Set-SapUserSetting -Key way_to_get_transport_request -Value <...> -Scope Session), not /update-config. Use -Scope Connection only if the
user says it should be the standing policy for that system from now on.
Step 1b — Verify Candidate TR (mode-aware)
Called from Step 1a's DEFAULT / ASK verify loops. Branches on
sap_dev_mode so a pure-GUI environment (no NCo, or hybrid environment with
the user's explicit GUI preference) never touches RFC just to look up a
status code. Symmetric to the Create Path dispatch above.
GUI branch (when sap_dev_mode = GUI, the default)
Invoke /sap-se16n to read the candidate TR's TRSTATUS directly from
table E070:
/sap-se16n TABLE=E070 WHERE: TRKORR=<candidate> SELECT: TRKORR TRSTATUS TRFUNCTION AS4USER Output file={RUN_TEMP}\se16n_E070.txt
Parse the resulting {RUN_TEMP}\se16n_E070.txt:
| Observation | Outcome |
|---|
ROWS=0 (NO_DATA) | TR genuinely not found in this system (empty result set). Loop back to the Step 1a prompt (DEFAULT/ASK) — invite the user to enter a different number or type new. |
QUERY_FAILED (se16n exits 1; the output file's first line is QUERY_FAILED<TAB><msg>) | The E070 read itself FAILED (authorization / lock / invalid table) — the candidate's status is UNKNOWN. Do NOT treat as "not found" and do NOT create a new TR (a transient error would otherwise cause TR sprawl). Surface the message; offer to retry or verify in SE01, then re-prompt per the Step 1a policy loop. |
TRSTATUS = D or L | Modifiable. Output RESULT_TR: <candidate> / RESULT_STATUS: EXISTING_MODIFIABLE. STOP — skip Steps 2-4. Apply persistence per Step 1a policy. |
TRSTATUS = R, O, or N | Released / release in progress / released with errors. Tell the user <candidate> is not modifiable; loop or offer to create a fresh TR via the Create Path. |
| Any other code | Unrecognized status — show the row to the user and ask whether to proceed or create a new TR. |
The E070-TRSTATUS lookup is a pure read against an SAP standard table and
does not require any write authorisation; the only prerequisite is the
active SAP GUI session that /sap-se16n itself depends on.
Customizing-mode extra checks (--type customizing only). Before accepting
a TRSTATUS = D/L candidate:
- Request class — the
TRFUNCTION you already selected must be W. If it
is K, tell the user "<candidate> is a Workbench request, not Customizing"
and re-prompt per the Step 1a policy loop (do NOT accept; do NOT auto-create).
- Client match — read the request's client:
/sap-se16n TABLE=E070C WHERE: TRKORR=<candidate> SELECT: TRKORR CLIENT Output file={RUN_TEMP}\se16n_E070C.txt
CLIENT must equal the pinned profile's client. Mismatch → "<candidate>
belongs to client <CLIENT>, not <pinned>" → re-prompt. ROWS=0 (no E070C
row) → the client is unconfirmable: warn COULD_NOT_CHECK client and ask the
user whether to proceed (never silently pass). Workbench mode skips both.
(In sap_dev_mode RFC/BDC, read E070/E070C with a direct RFC_READ_TABLE
instead — both are directly readable; the verify PS1 confirms modifiability
and this gate is applied on top.)
RFC / BDC branch (when sap_dev_mode ∈ {RFC, BDC})
Fall through to Steps 2-4 below. The PS1's verify branch routes
TR_READ_REQUEST through Z_GENERIC_RFC_WRAPPER_TBL (TR_READ_REQUEST is not
remote-enabled, so the direct NCo path fails to bind the deep TRWBO_REQUEST
structure). The wrapper must already be deployed via /sap-dev-init.
The PS1 is verify-only on this route — it NEVER creates a substitute TR
when given a candidate. Interpret its machine lines:
| Line (exit code) | Meaning | Action under DEFAULT / ASK |
|---|
RESULT_TR: <TR> + RESULT_STATUS: EXISTING_MODIFIABLE (0) | Candidate is modifiable | Use it; persist per the Step 1a policy. |
RESULT: TR_NOT_MODIFIABLE trkorr=<TR> status=<R|O|N|NOT_FOUND|...> (1) | Candidate is released / release in progress / not found | Re-prompt the user per the Step 1a policy loop ("provide a different modifiable TR, or new"). NEVER silently substitute a freshly created TR. |
RESULT: TR_UNVERIFIED reason=<...> (1) | Wrapper missing / transient RFC error — the candidate's status is UNKNOWN | Do NOT treat as not-found and do NOT create. Surface the reason; offer to retry, or to verify via /sap-se16n on E070 (works whenever a GUI session exists), then re-prompt per the Step 1a policy loop. |
Step 2 — Read SAP Connection Parameters
Read SAP connection parameters from the merged sap-dev-core settings (per shared/rules/settings_lookup.md — settings.local.json overrides settings.json per-key on the .value field):
| Setting key | Maps to token | Example |
|---|
sap_application_server | %%SAP_APPLICATION_SERVER%% | 10.0.0.1 |
sap_system_number | %%SAP_SYSTEM_NUMBER%% | 00 |
sap_client | %%SAP_CLIENT%% | 100 |
sap_user | %%SAP_USER%% | DEVELOPER |
sap_password | %%SAP_PASSWORD%% | (masked) |
sap_language | %%SAP_LANGUAGE%% | EN |
If settings are not configured, ask the user to provide the values and suggest
they configure settings.json for future use:
"SAP connection settings are not configured. Please provide the connection details,
or configure them in sap-dev-core settings.json for automatic use."
Step 3 — Generate and Run PowerShell
Reached only when sap_dev_mode ∈ {RFC, BDC} — either to verify a
candidate (Step 1b RFC/BDC branch) or to create a new TR (Step 1a Create
Path RFC/BDC branch). GUI mode never reaches this step: Step 1b GUI uses
/sap-se16n for verify and Step 1a Create Path GUI uses /sap-se01 for
create.
The PowerShell template is at <SKILL_DIR>/references/sap_transport_request.ps1.
Write {RUN_TEMP}\sap_tr_run.ps1:
$content = [System.IO.File]::ReadAllText('<SKILL_DIR>\references\sap_transport_request.ps1', [System.Text.Encoding]::UTF8)
$content = $content.Replace('%%SAP_APPLICATION_SERVER%%', '')
$content = $content.Replace('%%SAP_SYSTEM_NUMBER%%', '')
$content = $content.Replace('%%SAP_CLIENT%%', '')
$content = $content.Replace('%%SAP_USER%%', '')
$content = $content.Replace('%%SAP_PASSWORD%%', '')
$content = $content.Replace('%%SAP_LANGUAGE%%', '')
$content = $content.Replace('%%RFC_LIB_PS1%%', '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_rfc_lib.ps1')
$content = $content.Replace('%%TRANSPORT_REQUEST%%', 'THE_TR')
$content = $content.Replace('%%SAP_DEV_MODE%%', 'THE_MODE')
[System.IO.File]::WriteAllText('{RUN_TEMP}\sap_tr_run.ps1', $content, [System.Text.Encoding]::UTF8)
Write-Host 'Done'
Replace all THE_* placeholders with actual values from Steps 1-2.
Replace <SKILL_DIR> with the absolute path to this skill directory.
Set THE_TR to the TR number from Step 1, or empty string "" if none.
Set THE_MODE to the resolved sap_dev_mode value (GUI / RFC / BDC).
The PS1 has two symmetric guardrails that catch SKILL.md dispatch bugs:
| Condition | Refusal message | Intended dispatch |
|---|
THE_TR empty + THE_MODE = GUI (create misroute) | TR creation via CTS_API_CREATE_CHANGE_REQUEST refused under sap_dev_mode=GUI | Step 1a Create Path GUI branch → /sap-se01 |
THE_TR non-empty + THE_MODE = GUI (verify misroute) | TR verification via TR_READ_REQUEST (wrapper FM) refused under sap_dev_mode=GUI | Step 1b GUI branch → /sap-se16n on E070 |
Both guardrails are intentional — under GUI mode the PS1 must not be
reached at all. If you see either refusal in production, fix the SKILL.md
dispatch in the caller, not the guardrail.
Execute via 32-bit PowerShell (SAP NCo 3.1 is registered in the 32-bit GAC):
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File "{RUN_TEMP}\sap_tr_run.ps1"
On the create route (Step 1a Create Path RFC/BDC branch — THE_TR set
empty), append the description built per rule_of_tr_description (and, for
--type customizing, -RequestType W):
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File "{RUN_TEMP}\sap_tr_run.ps1" -Description "<built description>" [-RequestType W]
(-CreateNew may additionally be passed to make the create intent explicit;
an empty TR input already implies it.) On the verify route (THE_TR
non-empty) pass no extra arguments — the PS1 is verify-only there and NEVER
falls through to creating a TR.
Step 4 — Interpret Results
Parse the script output for RESULT_TR: and RESULT_STATUS: lines (and, on
verify failures, the machine lines RESULT: TR_UNVERIFIED reason=<...> /
RESULT: TR_NOT_MODIFIABLE trkorr=<...> status=<...>).
| RESULT_STATUS | Meaning | Action |
|---|
EXISTING_MODIFIABLE | Provided TR is still modifiable | Report: "Transport request <TR> is modifiable and ready to use." Persistence per Step 1a (policy-driven). |
NEWLY_CREATED | New TR was created | Report: "Created new transport request <TR>." Persistence per Step 1a: DEFAULT → save automatically; ASK → ask the user once; CREATE_NEW → do NOT save. Persist via the SESSION writer (sap_dev_default.ps1 / Set-SapUserSetting -Scope Session), NOT /update-config. |
TR_NOT_MODIFIABLE | Candidate TR is released / release in progress / not found (status= on the RESULT: line); nothing was created (exit 1) | Under DEFAULT/ASK, re-prompt the user per the Step 1a policy loop ("different modifiable TR, or new"). NEVER silently substitute a new TR. |
TR_UNVERIFIED | Wrapper missing / transient RFC error — candidate status UNKNOWN; nothing was created (exit 1) | Do NOT treat as not-found. Surface the reason=; offer retry or a GUI verify via /sap-se16n on E070, then re-prompt per the Step 1a policy loop. |
ERROR | Something went wrong (create failure exits 1 too) | Show full output and diagnose (see error table below). |
Error Diagnosis
| Error | Cause | Fix |
|---|
NCo 3.1 not found in GAC_32 | SAP NCo 3.1 not installed for .NET 4.0 32-bit | Install SAP NCo 3.1 for .NET 4.0 (32-bit) per SAP Note |
RFC logon failed | Wrong server/credentials | Check SAP connection parameters in settings.json |
TR_READ_REQUEST call exception | FM not accessible or TR format wrong | Verify S_RFC authorization; check TR number format |
CTS_API_CREATE_CHANGE_REQUEST call failed | Missing authorization or CTS not configured | Check S_CTS_ADMI and S_TRANSPRT authorizations |
returned empty request number | TR created but number not returned | Check SE10 manually for recently created requests |
Step 5 — Clean Up
cmd /c del "{RUN_TEMP}\sap_tr_run.ps1"
Final — Log End
Log the run-end record. Best-effort.
On success:
powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action end -StateFile "{RUN_TEMP}\sap_tr_run.json" -Status SUCCESS -ExitCode 0
On failure:
powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action end -StateFile "{RUN_TEMP}\sap_tr_run.json" -Status FAILED -ExitCode 1 -ErrorClass <CLASS> -ErrorMsg "<short>"
Suggested <CLASS>: TR_RESOLUTION_FAILED, TR_NOT_MODIFIABLE, TR_UNVERIFIED, RFC_LOGON_FAILED.
Security Note
The generated .ps1 file contains the SAP password in plain text. It is deleted
automatically after execution (Step 5). Connection parameters are stored in
settings.json. The password field is marked as sensitive and masked in the Claude Code UI.
32-bit Note
SAP NCo 3.1 is registered in the 32-bit GAC (C:\Windows\Microsoft.NET\assembly\GAC_32)
when installed for .NET 4.0 32-bit. Always execute via
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe to ensure 32-bit assembly load.
Important: Encoding
PowerShell scripts are written as UTF-8 (no BOM); NCo handles SAP unicode automatically.
