Skip to Content

UDO tool – Simplifying Upports and Downports

With lot of teams driving customer connect projects, the amount of development done for those are pretty high, and SAP has to release the changes in the lower releases either for legal reasons or to support customers in their current releases.

During the execution of these customer connect projects , along with the code changes , we create/modify lot of DDICs and associated documentations.

To ship the changes in notes is a pretty challenging effort as lot of analysis has to be done as to which object goes where and it has to be ensured that the new changes does not disrupt anything already existing. Usually in these cases the notes released are pretty high and also complex as they have lot of objects in them.

As everybody is aware, SCWB/SNOTE does not support downport of documentation, DDICs , Message classes, Messages, Table Contents.

As a result the developer writes manual steps for DDICs and messages in the note and documentation is released along with the support pack.

There is a lot of chance that the manual steps might not be complete / have some ambiguity and hence it might lead to problems during the implementation in the customer landscape.

UDO tool simplifies this process of downporting by generating a report which will be saved in the system in the normal deliverable package and be shipped in a note. This report when executed will take care of the DDICs and Documentation and creates and activates them in the target system.

The code changes as earlier goes in a separate note , as that does not have any manual activity.

Without the tool, the developer creates/ modifies the DDICs in the target system and then downports the code changes, as the coding might refer to the new/modified DDICs. So retaining the same logic, the note containing the generated report is a prerequisite to the note containing the coding changes.

So for a developer, this tool saves a lot of time as it avoids writing manual steps and takes care even the documentation and table contents and for the customer it saves a lot of effort as customer need not create/modify DDICs manually thereby avoiding the chance of manual mistakes.

Our team has used this tool and we have observed that the customers did not face any problems during implementation of those notes, and hence it saved significant effort for development team as well as customers.

Kindly use this tool and provide your valuable feedback in comments.

You must be Logged on to comment or reply to a post.
  • Hi,

    I created new methods in existing class. But these new methods are not listed in UDO tool report. What do I need to do to get these methods listed by UDO report?



  • Hello,

    I have a similar question. A UDO report created i.e. structures and data elements. But we undo the note implementation. And now there are remaining objects from the UDO report.

    Is it possible to undo these changes also without manually modifying all elements?




    • One of our developers confirmed that below " By executing UDO Report are not reversible. If needed those changes should be reverted manually.

  • While I agree it's easy for customers and developers for CREATION or an initial setup it's a mess for everything coming thereafter:

    • if a new note version with UDO and subsequent corrections comes out SNOTE cannot determine whether or not only the coding changes need to be done or the UDO-report was changed too - there will be no popup.
    • after an upgrade of a system there is no dependency check (which UDO-note needs to be re-executed in which sequence of other UDO-notes).
    • the objects created via UDO are technically not connected to the note object and while the note itself can be maintained and considered obsolete the objects created by UDO still appear in SPDD and/or SPAU and the customer does not know where they came from and whether they can or cannot be reset to default because there's no technical link to the note object.

    If one has applications (such as AIF/eDocument) completely delivered using UDO and one has to maintained several dozens of notes after an upgrade one will understand those points.

    I opened several incidents in the past asking how to handle those cases and the answer is always "there is no answer" and "please execute the report again to make sure".

    Until those problems are resolved and there is some sort of tooling for those objects I'll refuse applying any more UDO notes in our systems.

    For me those UDO-notes are putting the implementation effort, responsibility and the work completely to the customer instead of creating compliant transports (TCIs), which have tooling for upgrades and conversions and which have rollback functionality. Or for bigger implementations create an AddOn but please stop creating programs, that randomly create objects objects in the system without the tooling to maintain them properly. Thank you.