Page Comparison

...

To find out what is really relevant, the following key questions offer you a good orientation.

...

Synchronize SAP metadata

In order to be able to interact with SAP objects, they must first be collected and written to the database via synchronization.

• Which SAP objects should be documented in the future?
  💡 Adapt synchronization and select the relevant object types for each connector.

• Is it enough to trigger synchronization manually, or does synchronization need to be automated because so many new documentation-worthy objects are created in the SAP system?

  💡 Set up and use the AutomationTool on a VM if synchronization is to be automated

...

Ad hoc documentation

• Is it enough to document individual objects?
  💡 Then start the documentation via the context menu of the SAP objects to be documented in the entity grid

• Which format is needed for which object type?
  💡 Word/PDF/Confluence or Excel (e.g. for Calc. Views, CompositeProvider, or Queries via SetCards)

• Do you want to document the dependent objects (PartProvider, DataSources etc.) under the object as well?

  💡 Activate the "Document complete data flow" option for InfoProviders in higher layers in order to obtain complete documentation up to the DataSource. Alternatively, you could also use Scenarios!

Additional Explanations

Comments can be used to add additional explanations to objects that cannot be read from the SAP systems (e.g. business objectives, explanations, or technical decisions).

Comment Templates

• What technical content is already available to us in an automated way through the Docu Performer documentation?
  💡 Document relevant objects and check the content

• Which further technical explanations and business information should be attached to the relevant objects?
  💡 Consider which content (in the form of a comment) should additionally be displayed in the documentation on the object and edit chapter structure via comment templates. You should do this only for the relevant object types!

Here are some suggestions on how the comment structure could look per object type

Commenting

• When should the comments be made?
  💡 After/during development? With every change?

• Should change management be covered by commenting?
  💡 Pay attention to comment status in the Entity Grid and activate Comment Explanation. Pay attention to comment status in the Entity Grid and activate Comment Explanation

Settings & Comment Variant

...

Define the level of detail

The level of detail can be defined for the technical information via the Settings Variant and the manually integrated explanations (comments) via the Comment Variant. It is only necessary to define multiple variants if more than one target group (e.g. IT + Business) will read the created documentation.

• Docu Performer automatically extracts a great deal of information regarding SAP metadata during documentation. Should all this information end up in the documentation or only parts of it?
  💡 Adapt existing settings variants or create new ones depending on the definition of the target groups.
  Some settings relevant for the settings variant are explained here.

• Which manually maintained content (comments) should be included in the documentation?
  💡 Create comment variants to define which comment chapters per object type should be considered for documentation.

Documentation

Ad hoc documentation

• Is it enough to document individual objects?
  💡 Then start the documentation via the context menu of the SAP objects to be documented in the entity grid

• Which format is needed for which object type?
  💡 Word/PDF/Confluence or Excel (e.g. for Calc. Views, CompositeProvider, or Queries via SetCards)

• Do you want to document the dependent objects (PartProvider, DataSources etc.) under the object as well?

  💡 Activate the "Document complete data flow" option for InfoProviders in higher layers in order to obtain complete documentation up to the DataSource. Alternatively, you could also use Scenarios!

...

Bundled documentation of SAP objects

• Is it necessary to document several SAP objects that are related (data model, application, key figure catalog, change request, transports etc.) in one document?
  💡 Then it makes sense to work with Scenarios! Several SAP objects can be assigned to the Scenarios in the Scenario designer or from other contexts (e.g. in the entity grid or data flow via the context menu).

• What do Scenario folders and Scenarios themselves represent organizationally? (Folder=Business line? Subject? Scenario=Application?)

  💡 Create Scenario folders and create Scenarios within the folders.

• What should be the general structure of a Scenario - can it be generalized for all future documentation via Scenarios?
  💡 Open Scenario in Scenario Designer, add structure elements, and define assignment rules (based on which SAP objects end up in the Scenario). Then the Scenario can be cloned to a Scenario Template to reuse the content/structure in the future.

• Who should create Scenarios and assign objects to them at what time and maintain them in the long term?
  💡 Create a Scenario (depending on the use case) based on the appropriate Scenario template, assign objects, and automate maintenance (add/delete objects).

• Is additional object information (graphical data flows, where-used lists, resolved key figures, maintained comments, etc.) required?
  💡  Activate/deactivate object type-specific settings on the object in Scenario Designer.

Automated Export

• Is it necessary that, for example, daily updated documentation is made available automatically?
  💡 Select Scenarios for automated export in the Performer Suite and schedule automated export in the AutomationTool.

...