SM35 — Batch Input Session Monitor

SM35 manages batch input sessions, which are queues of recorded screen-navigation data (dynpro id, field name, field value) generated by programs that simulate a user typing through a transaction screen by screen. Interfaces such as LSMW using the batch input recording method, or older custom programs calling the batch input function modules, write these queues instead of posting directly. SM35 is where those queues get processed, either in the foreground with the consultant clicking through each screen, or in the background as a scheduled job. The structural fact that causes most confusion is that SM35 operates at the queue level. A session can complete and disappear from the worklist as processed while several transactions inside it ended in error status, because the session engine keeps moving to the next transaction record after a failure unless told otherwise.

SM35 is reached for during data migration cutover when legacy interfaces still use classic batch input rather than BAPIs or IDocs, during recurring load jobs such as bank statement uploads or bulk HR changes built on old recording-based programs, and when troubleshooting a queue that appears stuck or partially failed. It is not the tool for BAPI-based or IDoc-based interfaces, which post directly or land in IDoc monitoring instead of a batch input queue. On newer implementations the Migration Cockpit and its Fiori-based load apps replace batch input entirely for cutover, but SM35 remains relevant wherever a legacy program or third-party middleware still generates classic sessions, and it stays the correct place to check when someone reports that a nightly interface run left a queue open overnight.

Query APQI on the session name and creation date range to get the session's overall status code and lock state. Take the session's internal identifier from that record and query BDCMSGCOLL filtering on the same session, then look at the message type per transaction number: any entry with message type E or A inside an otherwise processed session proves that individual transactions failed even though the session itself closed. Cross-check the transaction number against the business document that was supposed to be created to confirm it is genuinely missing rather than just delayed.

SM35 exists and behaves the same way on S/4HANA; the underlying batch input engine and session tables are unchanged. What has changed is which interfaces still generate sessions: current cutover projects are pushed toward the Migration Cockpit and its BAPI or OData based load approach, which does not create batch input queues at all. Custom programs and older LSMW recordings that still call the classic batch input function modules continue to run and land in SM35 exactly as before, so the transaction has not been deprecated, only sidelined for new migration work.

Functional consultants own the content of the session, the correctness of field values, and confirming that documents actually posted. Basis or the interface development team owns stuck locks, background job scheduling for large sessions, and authorization setup for the processing user. A clean handover includes the session name, the transaction number that failed, the exact error message from the analysis log, and the screen field it points to.

SM36 is the natural next stop for scheduling large sessions as background jobs instead of running them in foreground dialog. SM50 and SM66 confirm whether a session that looks stuck is actually still being worked by a live process. SM13 is worth checking when a batch input transaction inside the session used update tasks that themselves failed asynchronously after the screen sequence completed. SLG1 is relevant where the calling program writes its own application log alongside the standard batch input message collection.