I have a requirement to send SAPscript output as a PDF to SAP cFolders. The context is a transaction for which user exits exist in the form of a BAdI, and it’s already implemented for something else, so I can just latch onto that. The code consists mostly of checking for the right conditions under which the document is to be sent, but the actual sending is the interesting part.
In effect, we’re calling the print routine for that SAPscript. The print routine imports the data it needs from memory, so our code exports all necessary data to memory, including a new flag indicating that we’d like to send a PDF instead of whatever other output method is called for. We change the print routine to read this flag, and make changes at two points: first, call the open_form function with the field tdgetotf of structure itcpo set to ‘X’, and second, instead of the normal call to close_form, call it with the otfdata table supplied. At this point, it’s just a simple call to convert_otf to convert the SAPscript-data into PDF format, either as a string or as a table.
Now we have the PDF, and we can do with it what we want. It could be saved locally, or, in this case, the string is converted to a table (it’s a different format than the table that comes out of convert_otf) and a custom function sends the table to cFolders.

We have an existing custom program that does an insert of an internal table into a custom database table, like this:
  INSERT ztable FROM TABLE it_table.
  COMMIT WORK.
Variable names are changed to protect the innocent. It short-dumped, for the obvious reason that there was a duplicate key somewhere. Now the short dump doesn’t really give any useful info, so I can’t figure out why there’s a duplicate key in the first place. The program’s not intended to update any existing records, just insert new ones, so catching that error and doing an update isn’t the solution. What I did was catch the exception, and then try to insert every line one by one, writing out the key fields for each, and marking the one for which the error occured. Like this:
  TRY.
    INSERT ztable FROM TABLE it_table.
  CATCH cx_sy_open_sql_db.
    FIELD-SYMBOLS: <ztab> TYPE ztable.
    FORMAT COLOR COL_KEY.
    WRITE: / text-006. "Duplicate key error for the following dataset:
    LOOP AT it_table ASSIGNING <ztab>.
      INSERT ztable FROM <ztab>.
      IF sy-subrc IS INITIAL.
        FORMAT COLOR COL_POSITIVE.
      ELSE.
        FORMAT COLOR COL_NEGATIVE.
      ENDIF.
  *   write the key fields to the report
    ENDLOOP.
    FORMAT COLOR OFF.
  ENDTRY.
  COMMIT WORK.

Nice. The program tends to process lots of data and can run a long time, so I want to keep the mass insert. But when it fails, it’ll write out the key fields of every record I’m currently trying to insert, with the good ones in green, and the bad ones in red. And whaddayaknow... it doesn’t work. Nope. In the debugger, I carefully craft an entry with identical key fields as one in the database table. This does trigger the exception, but the line-by-line insert goes over it as if nothing is wrong. It’s not updating the database for that one line, but it’s not reporting an error either.
The solution, after much thought, turned out to be simple: when the exception is raised, roll back the mass insert before doing the individual inserts:
  TRY.
    INSERT ztable FROM TABLE it_table.
  CATCH cx_sy_open_sql_db.
    ROLLBACK WORK.
  ....
Now the offending entry shows up in red. All we need to do now is wait for the error to occur again, and then go digging through the data to see why there’s a duplicate...