SAP STMS传输请求报错无法重新传输请求

最新推荐文章于 2024-12-11 17:57:47 发布
原创 最新推荐文章于 2024-12-11 17:57:47 发布 · 1.6k 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#sap #erp #ABAP

当传输请求号至测试系统时出现错误，首次尝试传输只完成了一半。使用E070表取消传输后，尝试再次传输时系统提示请求号已存在，不允许重复传输。为解决此问题，需将请求号重新加入导入队列，然后执行重传操作，这样可以成功传输。

1.问题描述

  在传输请求号的时候，第一次传输到测试系统是传输一半，报错；用表E070取消传输后，再次传输报错该请求号已经传输，无法再次传输。
在这里插入图片描述

2. 解决方案

  把这个请求重新加入到导入队列，然后再重传。就可以了。
在这里插入图片描述
在这里插入图片描述

SAP ABAP 系统传输请求(Transport Request)导入到其他系统背后执行的逻辑
2007 年 ~ 2025 年，深耕 SAP 技术 18 年
09-28 650
在 SAP 系统中，当我们需要将一些更改从一个系统（例如开发系统）传输到另一个系统（例如测试系统）时，我们会使用 Transport Request。当你释放 Transport Request 并将其导入到测试系统时，系统会按照 Transport Request 中的指示，在目标系统中重新创建 Dynpro 程序。当你在开发系统中编写 Dynpro 程序并保存到 Transport Request 中时，你实际上是在创建一个包含你的 Dynpro 程序和相关代码的包。系统将代码导入到新创建的对象中。
在 SAP ECC 中配置公司码时遇到 “定制请求（Customizing Request）” 提示无法保存的问题，通常与 SAP 的传输管理机制相关
金牌架构师
09-23 569
在SAP ECC中配置公司码时若遇到定制请求无法保存的问题，可通过以下步骤解决：首先理解定制请求是SAP用于同步配置变更的工具。解决方案包括：1）在提示窗口创建新的定制请求；2）检查用户权限和客户端环境（需在开发客户端操作）；3）创建请求后需通过STMS事务码传输配置。如仍无法解决，建议联系SAP Basis团队确认权限和传输策略设置。该问题通常与SAP的传输管理机制相关，需确保配置变更被正确记录和传输。
SAP银企直连 将消息发送到 SAP Multi-Bank Connectivity MBC
SAP ABAP PO PI 银企直连
09-19 693
复选框来显式请求重新发送先前已发送的消息。在这种情况下，系统创建先前已发送消息的副本并触发其发送。原始（先前已发送）消息不会再次发送。创建要重新发送的消息副本时，系统会将原始消息分配为已复制消息的父消息。复选框，则即使选择条件中包括任何先前已发送的消息，系统也会移除这些消息。因此，在这种情况下，仅触发未决消息的发送。该程序通过从表 /BSNAGT/FILE_INF 中读取消息状态来识别相关消息。中显示父消息来导航到原始消息。您有权使用发送消息报表。来包括先前已发送的消息。TemSe 对象名称。
SAP TR请求相关总结
qq_36952606的博客
05-16 2894
5、查看TRBAT Table，发现TRBAT里仍有两条记录，从时间戳所标识的时间来看，这两条记录已过去很长时间了，且自此时间后所有的请求传输都不能结束，可以断定是由于此传输任务未结束导致后续请求无法传输，因此将这两条记录清除(delete)。3、将处于锁定状态下的任务解锁，解锁的方法就是将相关表TMSTLOCK*里的记录清除(delete)，delete的前提条件是确保所有delete的任务都已经传输到目标Client。STMS传输请求，不论等多久的时间，请求状态一直是running，不能结束。
“今天星期五“-SAP SE09/STMS 请求号传输中遇到的错误及解决方案
Sunflower
10-22 1965
当我们在写报表,程序,接口等最好把相同功能下的源代码,透明表,结构等放在一个请求号中,不然就会像我一样出现细节性的错误.这样你在传输的过程中也比较方便,千万不要创建太多的请求号,我是已经弄混了.
SAP重新传输请求
nopicture的博客
04-19 837
将需要的请求重新合并成一个新的请求。苏州 2023.4.19。
SAP STMS传输请求
weixin_43657667的博客
12-05 2124
主要由100：沙盘系统：用于业务顾问配置200：开发系统：用于开发ABAP写代码300：测试系统：主要是单元测试、顾问自己做一些配置的测试500：UAT测试系统：主要用于集成测试和用户接受测试，账号都是带权限的账号）600：数据验证系统：主要是用于月结模拟、正式环境会COPY到该环境，用于刚上线的系统前几个月的月结测试。800：正式系统：就是正式用户所使用的系统，业务实际发生的系统。项目中的系统配置一般都是从100环境进行配置，然后通过请求号的形式到测试环境，进行测试，测试无误后，
SAP STMS 传输进程卡死解决步骤
qq_55488207的博客
10-07 327
如图所示，STMS传号两小时，都还显示在传号，大概是卡住了。： 用于协调批 ABAP/UNIX 进行传输的作业标识。STMS里状态变绿了，可以重新上传了。根据请求号判断，就是这个卡住的一笔。然后按照大佬的步骤一步一步检查。： 传输控制的通讯表。查到如下两个表有数据。
关于SAP STMS 请求长时间导入的问题
P9QCer的博客
12-11 596
在client 000 中检查Job 是否正常启动：（Job Name： RDDIMPDP）注意：目前在运维过程中遇到大量的请求号没有经过传输队列的调整，导致传输请求过程中时间太长。确定后，再次回到需要传输的client，等待一段时间，检查传输是否恢复正常。请求传输时间过长，且后台没有任何报错。传输时间长达4个小时，这本身有一定的问题。点击调整传输队列后，然后再进行请求传输。3.获取message服务正常启动。2.执行RDDIMPDP。
SAP导入请求D01K900481已经运
07-12
这是因为tp.exe是SAP传输管理系统的一个重要组件，负责处理传输请求。如果此进程仍在运行，则可能会影响到后续的操作。 - **检查方法**：可以通过任务管理器或其他系统监控工具检查是否有tp.exe进程正在运行。 ###...
SAP 传输请求在本系统中被修理
BlueTeethBoy的博客
04-20 1362
SAP报错传输请求在本系统中被修理的解决方案
SAP STMS请求重复传输
IamRunjiang的博客
03-20 1071
SAP STMS请求重复传输
SAP ABAP 传输表失败是为什么
月阴荒的博客
07-15 582
（传输失败大概是因为创建域的请求没有传输过来）点击这个红点可以看到报错位置。
SAP传输错误
beyond911的专栏
02-24 1937
文章目录
SAP STMS报错（组件版本测试中找不到数据文件）引发的后续问题处理
se80工作者，记录问题与解决方案
10-08 2663
SAP STMS报错（组件版本测试中找不到数据文件）引发的后续问题处理
请求传输不成功的解决方案
如果没有了SAP我们还会什么？
07-31 3125
请求传输出现小车一直不动，查看传输日志 根据日志提示查看 DEV_EVT 通过查看NOTE44927、NOTE642464 需要设置systerm_pf
SAP 请求重新导入
王佐儿z的博客
11-07 2614
发生原因 解决步骤 由于请求报错是因为 修改对象 在当前系统被修改过 即已经包了请求 so 传输时应该覆盖传输 即可 选中传输即可 ...
关于请求
黄立
05-13 1689
1.打包请求 如果有多个请求sap传请求可以讲多个请求一起打包传，而且如果请求之间有依赖关系也不会报错，听上去似乎比bw要好一些。包请求过程如下： 选中一个请求后，点击 最左边的小图标。接着输入请求号，如图： 2.打包整个function group 原因暂时不清楚，问题没有重现，写了一个函数结果传到qas之后发现只传过去一个函数，function group却没有传过去！尝试修改f
SAP 已经Release(释放)的传输请求(TR)重新传输-SE03
热门推荐
王小磊
12-15 1万+
TR传输过程中可能会遇到一种情况：已经传输的TR，需要将其下面的所有对象（Objects）重新传输，这里介绍一种重新传输已经释放TR下的Objects的方法： Step1：T-CODE:SE03 Step2：双击上图的"Merge Object Lists" Step：在Request/Task栏位输入已经release的TR ，可以输入一个也可以输入多个 Step4：点击“执...
sap请求号一直在传输
最新发布
09-29
<think>嗯...用户这次的问题是关于SAP请求号持续处于传输状态的原因分析和解决方案。从用户提供的引用内容来看，ta应该是个SAP运维人员，遇到了请求卡在传输流程中的棘手问题。 用户引用了三段关键信息：第一段提到client日志满导致应用挂掉，正好发生在传输过程中；第二段详细说明了如何修改请求状态；第三段则涉及"被修理对象"的覆盖传输问题。这些线索都很重要，需要串联起来分析。 最可能的原因有三个方向：首先是技术层面的资源问题，比如日志空间不足导致传输中断；其次是传输请求本身的状态异常，需要人工干预修改；最后是被传输对象存在冲突，比如代码在目标系统被临时修改过。 解决方案要分步骤走：先检查基础资源是否正常（引用1中的日志空间）；再确认请求状态是否需要回退（引用2的RDDIT076程序）；最后处理对象冲突（引用3的覆盖选项）。用户作为专业人员，应该需要具体的事务代码和操作细节，比如SE09查看状态、STMS监控传输队列这些关键步骤。 考虑到用户可能正处于紧急故障处理中，回复要重点突出可操作性强的方法。特别是引用2提到的几种状态修改方案很实用，但要注意提醒用户修改生产系统请求状态的风险。另外用户没有说明开发/生产环境差异，这点需要在注意事项里补充说明。 </think>好的，这个问题在SAP传输管理中很常见。请求号一直处于“传输中”的状态通常意味着传输过程遇到了障碍或停滞。结合您提供的引用信息和常见原因，以下是详细分析和解决方案： ### 原因分析 [^1][^2][^3] 1. **资源耗尽或系统问题 (如日志满导致应用挂起)：** * **描述：** 这是最直接的物理障碍。目标系统（如Client 500）的关键资源（最常见的是数据库日志空间已满，也可能涉及表空间、内存、后台作业进程等）在传输过程中耗尽，导致传输程序本身挂起或终止。此时传输请求会卡在“正在导入”或类似状态。 * **引用关联：** 引用[1]明确描述了因Client-500的日志满了导致应用挂掉，阻塞了请求ED1K929912的导入。 * **表现：** STMS传输队列中该请求状态长时间停滞，目标系统可能出现性能问题或报磁盘空间不足错误。 2. **传输请求状态异常或冲突：** * **描述：** 请求的状态本身可能存在问题或被锁定。 * **未成功释放：** 请求在源系统未正确释放（状态可能不是`R`）。 * **目标系统中途中断状态未清理：** 上次导入尝试失败后，请求在目标系统的导入状态未正确复位。 * **锁定冲突：** 请求或其中包含的对象被其他用户或进程锁定（例如，有人在目标系统编辑同一个对象）。 * **错误修改请求状态：** 如果尝试过手动修改请求状态（如引用[2]所述），操作不当可能导致状态不一致。 * **引用关联：** 引用[2]核心就是讲解如何修复请求状态（如强行从`R`改回`D`），这侧面说明了状态错误是导致传输问题的一大原因。 * **表现：** STMS队列中请求状态异常（如卡在`Importing`、`Import Requested`但长时间不动）。查看请求日志(`STMS -> Requests -> Display Log`)可能会有关于状态冲突或锁定的提示。 3. **目标系统中的对象冲突：** * **描述(“对象被修理”或“对象锁定”)：** * **对象被修理：** 目标系统中的对象已被本地修改过（例如，通过紧急修复`REPAIR`或在QAS/PRD直接修改代码），使其版本高于或冲突于待传输的版本。系统检测到冲突并暂停传输。 * **对象被锁定：** 目标系统中待覆盖的对象正被其他用户或进程（如作业、用户编辑）占用。 * **引用关联：** 引用[3]的核心就是描述这种情况及其解决方案（强制覆盖）。 * **表现：** 在STMS导入队列中选择该请求查看详情(`Import Overview -> Detail Display`)，通常会看到一个或多个对象的状态是红色的“错误”（`Error`）。双击错误行或查看日志文件会明确提示“对象被修理”、“对象已被修改”、“对象被锁定”等具体错误信息。引用[3]提到的函数组内其他函数影响传输的情况也属于此类冲突。 4. **传输管理系统(STMS)内部问题或通信故障：** * **描述：** STMS配置问题、后台作业调度失败、网络瞬断或域名解析问题等，导致传输过程未能正常启动或中断。 * **表现：** STMS队列整体状态异常，请求长时间处于`Import Requested`状态但从未启动导入，或导入进程莫名消失。系统日志可能记录相关错误。 5. **高负载或长时间运行：** * **描述：** 请求非常大或包含需要长时间处理的对象（如大数据量的表调整），在高系统负载下导入速度极慢，看起来像卡住。 * **表现：** STMS导入日志显示导入仍在缓慢进行，系统负载较高。需要与管理员确认请求大小和系统状态。 --- ### 解决方案与排查步骤 **第一步：检查基础资源与STMS状态** 1. **检查目标系统资源：** * 登录目标系统(`Client 500`)。 * 检查数据库日志空间 (`SM51 -> DB02` 或 `DBA Cockpit`)。如果空间耗尽，联系DBA清理或扩展。 * 检查表空间`PSAPBTABD`和`PSAPPOOLD` (`DB02`)是否充足。 * 检查后台作业进程是否充足(`SM50/SM66`看是否有大量作业等待)。 2. **检查STMS整体状态：** * 登录TMS Domain Controller系统。 * 执行事务码`STMS`。 * 检查传输域(`Overview -> Systems`)中所有系统状态是否为绿色(绿灯)。检查传输路由(TCP/IP连接)是否正常。 * 检查传输队列(`Import Queue for <目标系统>`)。确认队列状态是否激活(`Active`)。 **第二步：诊断卡住的请求** 1. **在STMS中定位请求：** * 在`STMS`中选择目标系统的导入队列(`Import Queue`)。 * 找到状态停滞的请求号。 2. **查看请求导入详情：** * 选中该请求，点击`Request -> Detail Display` (或按`F7`)。 * 查看**状态概览(`Status Overview`)**：确认当前导入步骤(如`Starting Import`, `Importing`, `Activating Objects`)。 * 查看**导入日志(`Import Log`)**：这是最关键的信息！双击日志文件链接(`Log File`)，**仔细阅读错误信息**。日志会明确指出是资源问题(空间不足)、对象冲突(被修理、被锁定)、状态错误还是其他具体问题。 3. **检查请求本身状态(跨系统)：** * 使用事务码`SE09`或`SE10`在**源系统(`Client 300`)**查看该请求状态，应为`R Released`。 * 在**目标系统(`Client 500`)**查看该请求状态(同样`SE09/SE10`)。在导入成功完成前，状态通常是`Importing`或`Import Requested`等。如果状态异常(例如变成`D`或怪异的锁定状态)，可能需要修复状态(参考原因2解决方案)。 **第三步：针对性解决方案** * **解决资源耗尽问题：** * 根据`Import Log`或系统监控(`SM51, DB02`)的提示，清理或扩展不足的资源(日志空间、表空间、作业进程)。 * 资源恢复后，通常需要**重新激活导入队列**(`STMS -> Import Queue -> Requests -> Activate`)或在队列管理中选中该请求**重新启动导入(`Request -> Restart Import`)**。 * **解决对象冲突问题：** * **对象被修理/锁定：** * 在`Import Overview Detail Display`中确认具体报错对象。 * 决定解决方案： * **覆盖原件：** 这是最常见的方法，也是引用[3]的核心方案。在导入队列中选择该请求，点击`Request -> Import with Overwrite Adjustment`。在弹出窗口中勾选： * `Overwrite originals` (覆盖原件) * `Overwrite objects in unconfirmed repairs` (覆盖未确认修复中的对象 - **关键！用于解决“对象被修理”**) * **手动解锁：** 如果报错是对象锁定(`Object locked`)： * 在目标系统使用`SM12`查看该对象的锁。 * 联系锁持有者释放，或评估风险后在`SM12`中删除该锁(谨慎操作！)。 * 执行覆盖导入后，监控日志确认导入成功。 * **解决请求状态问题：** * **仅在确认必要且目标系统状态异常时操作(风险高！)：** * **方法1 (推荐)：** 在目标系统运行程序`RDDIT076` (事务码`SE38`)。输入卡住的传输号(`TR Number`)，将其状态从`R`(或其他阻塞状态)改回`D`(Modifiable)。然后尝试重新导入。 * **方法2 (谨慎)：** 如引用[2]所述，在目标系统直接修改表`E070`。**极其不推荐，仅在其他方法无效且了解风险时尝试。** ```abap UPDATE e070 SET trstatus = 'D' WHERE trkorr = '<卡住的请求号>'. COMMIT WORK. ``` * **关键注意：** * 修改状态前务必备份(`SE09`导出请求或`TR_EXPORT`备份)。 * 优先尝试`RDDIT076`。 * 修改后状态变为`D`，需要检查请求内容是否完整，然后可能需要先在目标系统重新释放该请求(`Release`)，再尝试重新在`STMS`中导入。 * 如果请求在源系统状态也有问题，也需要在源系统类似修复。 * **处理STMS通信/内部问题：** * 检查`STMS -> Overview -> System`中目标系统是否在线(绿灯)。 * 检查传输目录(`DIR_TRANS`)权限和空间(`AL11`)。 * 尝试重新激活传输管理系统：`STMS -> Overview -> System -> SAP System -> Distribute and Activate Configuration` (或在命令行执行`tp connect pf=<TPPROFILE>`检查TP连接)。 * 重启目标系统的`SAPSTARTPRD`服务(操作系统级别)。 * 检查网络连通性、DNS解析。 * **处理大请求/高负载：** * 监控导入日志(`STMS -> Request -> Detail Display -> Import Log`)，看进度是否在缓慢推进。 * 联系系统管理员确认系统负载。如果是，考虑在业务低峰期尝试导入或分割大请求。 --- ### 总结流程建议 1. **`STMS` -> 进入目标系统导入队列 -> 选中卡住请求 -> `Detail Display` (`F7`)。** 2. **重点阅读`Import Log`文件中的错误信息。** 这是诊断的黄金标准。 3. **根据日志错误采取针对性动作：** * 空间不足 -> 清理/扩展资源 -> 重启导入队列或请求。 * `Object is being repaired` -> **导入时勾选`Overwrite Objects in Unconfirmed Repairs` + `Overwrite Originals`**。 * `Object is locked` -> 用`SM12`解锁或等待。 * 状态异常 -> (谨慎评估后)用`RDDIT076`修复请求状态。 * 其他STMS错误 -> 检查系统状态、配置、网络。 4. 资源修复或冲突解决后，通常需要**重新激活队列**或**重启该请求的导入** (`Request -> Restart Import`)。 ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

SAP顾问李昂

你的创作将会激励我，谢谢

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值