7/10/2024

Defense & Security

Generated on: 2024-07-10 10:50:56 GMT+0000

SAP S/4HANA | 2023 Latest

PUBLIC

Original content: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e08e0da88aa64d9095334cdb5fa3b25d?locale=en-

US&state=PRODUCTION&version=2023.001

Warning

This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.

For more information, please visit the https://help.sap.com/docs/disclaimer.

This is custom documentation. For more information, please visit the SAP Help Portal 1
 7/10/2024

Disconnected Operations

Use
Armed forces, police organizations, and aid organizations must respond to the challenge of operating in communication-
challenged environments, where connectivity to their SAP S/4HANA Defense & Security solution is not always guaranteed due
to the following reasons:

The type of connectivity often varies according to the location or situation involved.

Data transmission costs may be too high for limited budgets.

Data transmission is degraded or not permitted for safety or operational reasons.

Transmission protocols restrict how data can be transmitted and stored.

Backend systems are not available (planned or unplanned).

These factors mean that armed forces, police organizations, and aid organizations need to use additional IT systems to provide
the required business continuity.

Architecture
Disconnected operations in the SAP S/4HANA Defense & Security solution enable customers to have one central system and
one or more remote servers.

Central System

The central system is an SAP S/4HANA system and covers the broad range of processes that are relevant to the armed forces,
police organizations, and aid organizations.

Remote Server

The remote server is an SAP S/4HANA system at a remote site and works offline in communication-challenged environments
and synchronizes to the central system when communication is possible to enable business processes across the landscape.

The remote server is used at permanent and partially permanent sites. It uses the same software as the SAP S/4HANA
installation in the central system. The remote server differs to the central system, in that it has a subset of features and data. It
communicates with the central system on an intermittent basis.

Prerequisites
Customers must also:

Activate the DFS_DISCONNECTED_STRATEGIC BC set

Establish RFC connections between the central system and the remote servers

Maintain the system landscape

Con gure number ranges

Delete HR-related data if the remote server was built using a client copy

Enable change protection

This is custom documentation. For more information, please visit the SAP Help Portal 2
 7/10/2024
Lock SAPGUI transactions to prevent users from creating master data in the remote system

Implement appropriate roles and authorizations to prevent users from creating master data using Fiori applications

Activate recording of local Customizing changes

Set up FMDERIVE for FM derivation

Business Objects
Business Objects

The following objects are synchronized between the relevant systems:

Organizational Flexibility

Force Element

Assignment to Force Element

Force Element Relationships

Generic

Classi cation

Document Info Record

Maintenance

Equipment

Functional Location

Measuring Point

Measurement Document

Work Center

Bill of Material (Functional Location, Equipment, and Material)

Noti cation

Order

Revision

Master Warranty

Permit

Reference Location

Reference Measuring Point

Task List

Production Resource / Tool (PRT)

Single Cycle Plan

This is custom documentation. For more information, please visit the SAP Help Portal 3
 7/10/2024
Strategy Plan

Multiple Counter Plan

Time Con rmation

Reservation

Master Parts List

Structure Gap

Flight Order

Change Master

Con guration Pro le

Materials Management

Material

NATO Stock Number (NSN)

Stock Transfer Requisition (STR)

Stock Transfer Order (STO)

Outbound / Inbound Delivery

Goods Movement for Outbound / Inbound Delivery

Storage Location

MRP Area

Batch

Flexible Material Planning Object (FMPO)

Form-Fit-Function Class (FFFC)

Super Session Chain (SSC)

Packing Instruction

Handling Unit

Packing Condition

Accounting

Activity Type

Activity Type Group

Cost Center

Cost Center Group

Pro t Center

Pro t Center Group

Internal Order

This is custom documentation. For more information, please visit the SAP Help Portal 4
 7/10/2024
Order Group

Cost Element

Cost Element Group

Rate

Product Safety

Phrase

Dangerous Goods

Hazardous Material

Hazardous Substance

Project System

Project

Work Breakdown Structure (WBS) Element

Change Protection

Change protection provides a mechanism to prevent users in a system from modifying objects to ensure business process
integrity within the landscape. It ensures that an object can only be modi ed in one system – the central system or a single
remote server.

Change protection associated with the objects in a subscription can be transferred to the target remote server with the initial
data distribution or separately at a later stage.

Change protection only applies to dedicated business object types.

Change Protection for Noti cations and Orders

Change protection for a noti cation or order is based on their main work center and to which system they belong.

When a noti cation or order is saved, and the work center belongs to a different system than where the noti cation or order is
saved, you can decide whether the change protection is to be distributed according to the work center involved.

In the case of a network of linked noti cations and a work order, the system ensures an all or nothing approach to change
protection distribution for the noti cations and the order for the network. This enables the linked noti cations and the order to
be edited in the system in which all of them have change protection.

Dialog box for a user decision about distributing change protection for a maintenance noti cation or order

If the noti cation or order header contains a work center whose ownership (change protection) is found in a different
system to the one in which the noti cation or order is currently being edited, the system displays a dialog box when you
save, asking you to make a decision about distributing the change protection for the noti cation or order.

The following options exist:

Cancel: The system does not save and returns to the edit mode for the noti cation or order

Yes: The noti cation or order is saved, and the change protection is distributed to the system in which the work
center has change protection
This is custom documentation. For more information, please visit the SAP Help Portal 5
 7/10/2024
No: The noti cation or order is saved without distribution of the change protection

Distribution of change protection for a network of linked noti cations and an order

A link between a noti cation and an order can exist as a result of the following:

Direct link of the noti cation and order (noti cation / order header)

Assignment of noti cations to the order object list

If a network of linked noti cations and an order exists, the change protection for all noti cations and the order for the
network must be found in the same system to ensure that they can be edited.

If the dialog box mentioned in 1) appears when saving a noti cation or order, if the user con rms with Yes, the system
distributes the change protection for both the edited noti cation or order, and also for all other noti cations / the order
of a potential network to ensure that the items in the network are all consistent and can be edited in a single system.

Transaction for analyzing the current change protection for each of the linked noti cations and order for a network and their
work centers

A new report has been delivered to provide a quick overview of where the change protection for each noti cation and
order of a network and their work centers currently resides.

The report can be started by entering one or more noti cations or orders for which the network and change protection
data is to be displayed.

Details of the report:

Transaction: DFS_DIS_NO_WO_CP

Transaction text: Transaction for NO/WO CP Network

System Landscape Administration

The lifecycle of a remote server covers the phases of System Setup, System Operation, and System Decommissioning.

Some of the steps described in the following sub-chapters may be relevant to other sub-chapters as well.

Example: Stopping the ongoing distribution of data for a speci c subscription to a remote server may be relevant during system
operation if the speci c data of the subscription is no longer relevant to the remote server, and is needed during system
decommissioning if data distribution for all subscriptions related to the remote server needs to be terminated.

System Setup
The system setup phase contains hardware-related steps as well as software-related steps.

The sub-chapters describe some of the main software-related steps required for initial data distribution from the central
system to a remote server.

Additional – and more technical information – can be found in the system setup guide.

Distribution of Local Con guration Data

This is custom documentation. For more information, please visit the SAP Help Portal 6
 7/10/2024
Within the context of the SAP S/4HANA Defense & Security solution, speci c Customizing tables exist which contain data that
is maintained directly in the productive system, unlike most Customizing data, which is transported into the productive system
via transport mechanisms from a development system.

For disconnected operations, this means that such speci c con guration data is not automatically available in the remote
server via system setup using system copy or transport mechanisms. It, therefore, needs to be otherwise distributed, before
master and transactional data is distributed to the remote server.

Such local con guration data can be distributed from the central system to a remote server using transaction
DFS_DIS_DISTRIBUTE.

Distribution of Individual Tables and Business Objects

In the case of most master and transactional data business objects, data distribution from the central system to a remote
server is done using data derivation in a subscription (see also Initial Data Distribution and Delta Distribution) or by using
automatic delta distribution. However, there are exceptions to this for some data where this approach is not possible, mainly in
cases where there is no dedicated dependency or derivation of the data from other relevant data.

Such data – be it individual tables or business objects – can be distributed from the central system to a remote server using
transaction DFS_DIS_DISTRIBUTE.

Speci c application data, such as the accounting groups is distributed using the transaction DFS_DIS_SAD.

Example: Table WPSORR - “Conversion rules for work centers”

Filter Out Completed Data

To reduce the data volume and thereby improve the system performance it is possible to lter out completed maintenance and
supply data from the initial data distribution.

Filtering out refers to completed or closed maintenance noti cations and work orders and to those supply documents where
the full supply process has been completed up to the nal goods receipt.

The following maintenance data can be ltered out from the initial data distribution:

Maintenance noti cations with the status closed

Maintenance work orders with the status technically complete or closed

Filtering out is controlled by parameters that can be de ned by the system administrator, specifying how many days in the past
the corresponding status must have been set for the maintenance document to be ltered out.

Example: All maintenance noti cations that were closed more than 100 days ago are not derived for the initial data distribution.

The following supply documents are ltered out from the initial data distribution if the entire supply process has already been
completed:

Stock transfer requisition

Stock transport order

Outbound delivery

Goods issue

This is custom documentation. For more information, please visit the SAP Help Portal 7
 7/10/2024
Inbound delivery

Goods receipt

Filtering out supply documents is not dependent on any parameters for “days in the past” as is the case for maintenance
documents, but is solely dependent on the completion status of all documents that are part of the overall supply process.

Initial Data Distribution

The initial data distribution is an overall process for the initial transfer of data that is speci cally de ned and determined from
the central system to a remote server.

It contains four phases:

1. De ne subscriptions

2. Derive data

3. Transfer data

4. Check out data

During the initial data distribution, the central system rst derives all dependent objects from the supported types starting
from the lead force element for the subscription.

Note that no derivation is performed for the additional objects assigned to the subscription.

Users can start or schedule the initial data transfer from the central system to the target remote server once the data
derivation process is complete.

De ne Subscriptions
Synchronization between systems in the landscape relies on subscriptions. To distribute data to a remote server, at least one
active subscription for the remote server must be de ned in the central system.

The subscription is a method used to de ne parameters that include the leading force element and that are relevant to the
follow-on phases of the initial data distribution process. Users can assign additional objects to the subscription for speci c
object types (equipment, address, force element, noti cation) from the supported object types.

The subscription de nition is the rst phase of the initial data distribution.

Derive Data
Data derivation is the second phase of the overall initial data distribution process. In this phase, the central system uses the
leading force element de ned in the subscription to determine the dependent data that is to be transferred to the remote
server. This produces a data derivation instance that contains all object item IDs that have been derived.

As long as the third phase, data transfer, has not yet been started, it is possible to repeat the data derivation to receive
accurate results for relevant data at any point in time. The latest result list for the data derivation is used for the data transfer.

Transfer Data
The data transfer is the third phase of the overall initial data distribution process. In this phase, the data that has been
successfully identi ed in the data derivation phase is transferred and then imported to the remote server.

This is custom documentation. For more information, please visit the SAP Help Portal 8
 7/10/2024
Full data sets are determined and imported to the remote server for the object instance IDs derived in the previous phase.

Users can start or schedule the data transfer from the central system to the target remote server once derivation is complete.

Check Out Data

The data checkout is the fourth and nal phase of the overall initial data distribution process. In this phase, the relevant
ownership and change protection for dedicated object types for the data imported during the data transfer phase is transferred
to the remote server.

Ownership or change protection is transferred to the remote server for the dedicated object type, enabling speci c business
objects to be edited or business processes to be executed in the remote server, whilst preventing this from happening in the
central system.

Users can start or schedule the data checkout from the central system to the target remote server once the data transfer is
complete.

Manage and Monitor Subscriptions

App ID: F6172

You can use this app to enable roles in a Defense & Security organization, such as a system administrator for disconnected
operations, to manage and monitor subscriptions for the initial data distribution from the central S/4HANA system to multiple
remote servers, representing S/4HANA systems at remote sites. These remote servers can work offline in communication-
challenged environments and synchronize to the central system when communication is possible, to enable business processes
across the landscape.

Key Features
You can use this app to do the following:

Filter for subscriptions

Display lists of subscriptions according to speci ed lter criteria and personalized list views

Display important data for each record in the list display, such as the subscribed force element, target system, validity
dates or the status of each phase of the initial data distribution

Create subscriptions where target systems, lead force elements or individual data instances are speci ed that are
relevant for distribution to the target system

Activate or deactivate a subscription

Schedule or manually start data derivation of data that is relevant for distribution

Compare data derivation runs

Schedule or manually start the data transfer of the previously derived data

Schedule or manually start the data checkout for the previously transferred data

Display lists of derived, transferred, checked out data

Display the status of the data derivation, data transfer and data checkout phases

Display errors and reprocess runs once any errors have been resolved

This is custom documentation. For more information, please visit the SAP Help Portal 9
 7/10/2024

Supported Device Types

Desktop

Tablet

Smartphone

Search
You can search for a subscription using the elds at the top of the initial screen.

You can also use the function Adapt Filters to select different criteria. You can use the value help or F4 to de ne speci c search
conditions.

View
Subscriptions are displayed in a list when you open the app. You can de ne a custom view and save this.

Structure
A subscription has a header section at the top of the screen and a series of facets below it that show different information.
These facets are as follows:

General Information

Additional Objects

Schedule

Data Derivation

Data Transfer

Data Checkout

 Note
For more information about the SAP Fiori launchpad and how to work with objects, see SAP Fiori Launchpad.

Creating a Subscription
Choose Create. The object page for the subscription appears for editing.

Enter a subscription name and short name, as well as a validity date. In the eld Target System, you enter the ID for the remote
server to which your data needs to be transferred.

Make sure that you also enter a force element. Otherwise, you cannot activate the subscription. The force element must have
the status Active at the point in time when you activate the subscription.

Once you have entered the relevant data, you can activate the new subscription created.

To update a subscription, you need to open the object page in the edit mode. Note that when the subscription has the Planned
status, you can edit all elds. Once you have activated the subscription, only a few elds can be edited.

This is custom documentation. For more information, please visit the SAP Help Portal 10
 7/10/2024

Basic Information about a Subscription

This topic explains the basic information that is recorded for a subscription.

Header
The header shows the key information about a subscription. You also see the status for the phases of the initial data
distribution.

If no status is available, the phase has not been started yet.

General Information
The General Information facet contains information about the subscription, the target system and the lead force element.

Additional Objects
All additional objects are listed here. Additional objects are those objects that are not automatically derived from the lead force
element.

To add an additional object to the subscription, you need to open the subscription in the edit mode.

Schedule
A calendar view is displayed here. Blocks for data derivation, data transfer and data checkout appear as soon as the respective
phase has been started or completed.

You also nd information about whether a run has also been scheduled for any of the phases.

You can schedule the data derivation, data transfer or data checkout run by choosing Manage Schedule.

As soon as you cancel the scheduled run, the information is removed from the scheduling calendar, and the run is displayed with
the status Canceled on the corresponding phase facet.

Related Information
Manage and Monitor Subscriptions

Data Derivation
You see a list of the derivation runs you have executed on this facet.

You can start the data derivation directly or you can schedule it for a later point in time. To derive the data directly, go to the
drop-down menu Data Derivation in the action bar and choose Derive Data. To schedule the data derivation, choose Schedule
Data Derivation in the same drop-down menu.

Please note that you can also start this action in the list view.

When you start the data derivation, the status for Data Derivation in the header changes either to Scheduled or In Process.
The result of each data derivation run is displayed on the Data Derivation facet. The data derivation run gives you information
about the number of objects that were derived and the status.

This is custom documentation. For more information, please visit the SAP Help Portal 11
 7/10/2024
To navigate to the derived data, open the derivation run. A table that contains all derived data appears.

You can see the source object, from which the object was derived for each derived object

Comparison of Two Derivation Runs

Use the Compare button to compare two derivation runs with each other. You enable the Compare button by selecting two
derivation runs.

 Note
Please be aware that only two derivation runs can be compared here.

In the compare section, you nd information about the two derivation runs you compare and a chart called Instance
Comparison.

This chart shows three lines:

Total Number of Objects: all objects

Common Objects: the number of objects is shown for those objects that are listed in instance 1 and instance 2

Unique Objects: the number of objects is shown for those objects that are listed either in instance 1 or in instance 2

These three lines can be used to lter the table below, which shows the (business) objects in both derivation runs. By clicking on
Common Objects, you lter the table so that you only see the objects that are listed in both instances. By clicking on Unique
Objects, you lter the table so that you only see the objects that are listed either in instance 1 or in instance 2. By clicking on
Total Objects, you see all objects in the table again.

Related Information
Manage and Monitor Subscriptions

Data Transfer
You see a list of your data transfer runs on this facet.

You can start the data transfer for your derived data directly or schedule it for a later point in time. To transfer the data directly,
go to the drop-down menu Data Transfer in the action bar and choose Transfer Data. To schedule the data transfer, choose
Schedule Data Transfer in the same drop-down menu.

Please note that you can also start this action in the list view.

When you start the data transfer, the status of the Data Transfer in the header changes either to Scheduled or In Process. The
data transfer can be scheduled and canceled multiple times, but can only be executed once, based on the latest completed
derivation run.

The details of the data transfer run display how many of the derived objects have been successfully transferred.

To navigate to the transferred data, click on the data transfer run executed. A table containing all transferred data appears. You
nd the details of an error on the Error Log facet.

If issues or errors occur during the data transfer run, the run can be continued by choosing Re-Process , after you have manually
resolved the causes of the issues.

This is custom documentation. For more information, please visit the SAP Help Portal 12
 7/10/2024
At the end of a successful data transfer, the Data Transfer Status is Completed and all of the expected object instances have
the status Success. You can display the data on your remote server.

Related Information
Manage and Monitor Subscriptions

Data Checkout
You see a list of your data checkout runs on this facet.

You can start the data checkout for your derived and transferred data directly or you can schedule it for a later point in time. To
check out the data directly, go to the drop-down menu Data Checkout in the action bar and choose Check Out Data. To
schedule the data checkout, choose Schedule Data Checkout in the same drop-down menu.

Please note that you can also start this action in the list view.

When you start the data checkout, the status of the Data Checkout in the header changes either to Scheduled or In Process.

The data checkout can be scheduled and canceled multiple times, but can only be executed once, based on the completed data
transfer run.

The details of the data checkout run display the derived and transferred objects to which change protection or data ownership
has been successfully transferred.

To navigate to the checked-out data, click on the data checkout run executed. You see here the transferred data for which the
transfer of change protection or data ownership has been executed.

The Data Checkout Status is Completed for the force elements for which the data ownership was transferred, and for other
derived object instances for which the change protection was transferred. You can now edit your data on the remote server, but
this is no longer possible in the central system.

Related Information
Manage and Monitor Subscriptions

System Operation
After a remote server has initially been setup and provisioned with the relevant data, the system can be used for the daily
activities, exchanging data with the central system whenever connectivity is available.

Delta Distribution
Once the initial data distribution has been initiated, the central system and the remote servers detect both the creation of new
instances, and any changes to existing instances of supported objects. These new or changed instances are distributed between
the systems after the completion of the data checkout as follows:

From the central system to one or more remote servers: If the instance is subscribed to by the remote server

From the remote server to the central system: All

This is custom documentation. For more information, please visit the SAP Help Portal 13
 7/10/2024

Monitor Disconnected Operations Systems

App ID: F7484

You can use this app to enable roles in a Defense & Security organization, such as a system administrator for disconnected
operations, to start with a high-level overview of the data distribution status between the central system and the remote
servers, and to drill down into the analysis of errors for each remote server where required.

Key Features
You can use this app to do the following:

Filter for relevant systems to be displayed in the list

Save lter as variants

Display status overview for each system in a card layout

View subscriptions created for each remote system

Navigate to supporting tools like generic data distribution, change protection distribution, and number range monitor

Display status of the connection between the remote server and the central system

Display customer-de ned system attributes

Display total number of queues with errors

Display number of outbound/inbound queues in different statuses

Display list of subscriptions created for the remote server, with option to navigate to the Manage and Monitor
Subscriptions app

Supported Device Types

Desktop

Tablet

Smartphone

Search
You can search for systems using the elds at the top of the initial screen.

You can also use the function Adapt Filters to select different criteria. You can use the value help or F4 to de ne speci c search
conditions.

View
Systems are displayed in a card view when you open the app. You can de ne a custom view and save it.

Structure
For each system, the high-level overview of distribution status can be displayed by navigating between the screens.

Each card displayed in this app represents one remote system that is linked to the given central system.

This is custom documentation. For more information, please visit the SAP Help Portal 14
 7/10/2024
For each card, the following details are displayed:

System name

Status of the connection between the remote server and central system

Customer-de ned system attribute (example: priority or responsible)

Total number of queues with errors

Central system:

Number of outbound queues in status new, in process, and error

Number of inbound queues in status new, in process, and error

Remote server:

Number of inbound queues - evaluated by acknowledgement queues sent from the remote server to the central
system - in status new and error

Button “View Subscriptions”: Quick view of list of subscriptions created for the remote server, with option to navigate to
the Manage and Monitor Subscriptions app.

Monitor Queues
App ID: F7190

With this app, you can display queue lists and details for the central system related to each of the remote servers connected to
it.

Key Features
You can use this app to do the following:

Use pre-de ned lter for queues, which can be adjusted

Display initial data distribution and delta distribution queue lists on different facets

Select various elds for display in the queue lists

Process or cancel queues

Display queue header attributes

Display list of objects (ID and type) with currently owning system and data transfer status

Display error log

Display synchronization monitor with acknowledgement queues from the target to the source system with their queue
status

Display dependencies to other queues

Supported Device Types

Desktop

Tablet

This is custom documentation. For more information, please visit the SAP Help Portal 15
 7/10/2024
Smartphone

View
A queue list is displayed when you open the app. You can de ne a custom view and save it.

Structure
For each system the following levels of information can be displayed by navigating between the screens:

List of queues related to initial data distribution

List of queues related to delta distribution

Queue details

Objects

Error log

Synchronization monitor with acknowledgement queues

Queue List
For each system card, the following queues can be ltered and displayed with their attributes in the queue list:

Queues created during initial distribution via subscription or during delta distribution

Outbound and inbound queues

Examples for attributes to be chosen for display for each queue in the list:

Source and target system

Object type

Number of objects contained within the queue

Subscription ID

Status (for example Error)

Administration data (Created/changed by/when)

Depending on the status of a queue, the following actions can be performed from within the list:

Process queues

Cancel queues

Queue Details
For each queue, the following details can be displayed:

Queue header attributes, such as :

System ID

This is custom documentation. For more information, please visit the SAP Help Portal 16
 7/10/2024
Subscription ID

Source system

Target system

Queue status

List of objects with attributes, such as :

Object ID and type

Owning system

Other systems to which the object was distributed

Data transfer status

Error log

Acknowledgement queues from the target to the source system with their queue status

Dependencies to other queues

Number Range Monitoring

In a distributed system landscape, you have to ensure that all number ranges for objects that could be created in any system
and can be distributed do not overlap across all systems. You do so by de ning distinct number range intervals.

You can perform a con ict check from a central system to see whether con icts exist between the number range intervals in the
different systems in your distributed landscape.

De ne the number range intervals at the earliest possible time, either when you set up a new system, or before you use number
range objects that have not previously been used.

Number Range Consistency Check for a Distributed System

Landscape
App ID: DFS_DIS_NMBRRNGE

You can use this app to check whether number ranges overlap with other number ranges for systems (in the disconnected
server landscape).

Key Features
You can use this app to do the following:

Get Data gets number range intervals from the central system and all its remote servers and stores it in the table
/ISDFPS/NRIV. This data is then used for the check.

Check Intervals checks whether intervals from the central system and its remote servers overlap with the intervals
de ned in the selection criteria.

Show Current Status of Data checks whether the global number range intervals gathered are up-to-date.

Supported Device Types

This is custom documentation. For more information, please visit the SAP Help Portal 17
 7/10/2024
Desktop

Tablet

Smartphone

Prerequisites
Execution is only possible in the central system.

Table /ISDFPS/ALE_SYS must be maintained for the central system and its remote servers.

The default value RFCDEST is used for the connection to the systems.

Use the transaction Number Range Consistency Check for a Distributed System Landscape (DFS_DIS_NMBRRNGE) or the
Global De nition button in this program to de ne the number range objects to be observed here.

You must specify the number range object name, set the globality reference to O and select the Active indicator. All other
parameters are not used in this program.

 Note
When migrating from SAP ERP Defense Forces & Public Security to the SAP S/4HANA Defense & Security solution, we
recommend clearing the table /ISDFPS/NRIV before starting the execution of the Get Data function for the rst time.

Selection
You can only use the selection criteria for Check Intervals and Show Current Status of Data.

If you do not enter any selection criteria here, the selection is performed for all systems, (sub-) objects and number range
numbers.

Get Data queries number range intervals for all active objects de ned in the Global De nition from the central system and its
remote servers.

Output
Get Data displays an ALV table that contains the number range intervals fetched. Information is given about systems that could
not be reached.

Check Intervals displays an ALV table that shows whether an interval (from the selection criteria) overlaps with intervals from
other systems in the distributed system landscape.

Show Current Status of Data displays an ALV table that shows whether the data for the selected intervals from the different
systems is up-to-date. Information shown is listed for each logical system and objects and only observes intervals within the
selection criteria.

Activities
Get Data tries to establish a connection to the remote servers and then query the current number range intervals from the
active objects de ned in the Global De nition in the central system that executes the program. These number range intervals
are then stored in the central system in the table /ISDFPS/NRIV.

The comparison with Check Intervals is performed using the latest available data for the intervals stored in the central system.

This is custom documentation. For more information, please visit the SAP Help Portal 18
 7/10/2024

Manual Distribution of Change Protection

In exceptional cases, deviating from the SAP standard logic for the distribution of change protection, a system landscape
administrator may be required to manually distribute the change protection for a speci c object, or for all relevant objects in a
subscription, either from the remote server to the central system or vice versa.

The following options exist when using the report for exceptional distribution of change protection:

Recall or resend

Recall refers to the distribution of the change protection from the remote server to the central system.

Resend refers to the distribution of the change protection from the central system to the remote server.

Distribution of change protection for a subscription or a speci c object

Subscription: The change protection is distributed for all relevant objects having been distributed as part of the
subscription ID entered.

Speci c object: The change protection is only distributed for the speci c object ID entered. It is only possible to enter
objects for which a change protection mechanism is in place.

Transaction: DFS_DIS_CP

Background Jobs

Inbound Transaction Queue Processor for Initial Data Distribution

(DFS_DIS_IBQ_TRANS_PROC_PROG)

A background job for the report Inbound Transaction Queue Processor for Initial Data Distribution
(DFS_DIS_IBQ_TRANS_PROC_PROG) must be scheduled in the central system and the remote servers to ensure the
consistent posting of inbound queues in the target system according to the queue status, mobile application, and date/time.
The queues must be picked up frequently to trigger the inbound processing.

Defense Disconnected Non-EFI Object Data Report (DFS_DIS_NONEFIOBJ_SYNC)

Some of the business objects have no automatic change detection mechanism (“EFI event trigger”) for the remote server
solution. To achieve a consistent update of delta information in the target system, a background job for the report must be
scheduled at regular intervals. The delta information is distributed using the mobile data object NONEFI_DATA.

Delta changes are distributed using the background job for the following business objects:

ACTIVITY_TYPE

CONFIGURATION_PROFILE

FORM_FIT_FUNCTION

GENERICPRT

MPLAN_STRATEGY

PERMIT

REFERENCE_LOCATION

This is custom documentation. For more information, please visit the SAP Help Portal 19
 7/10/2024
REFERENCE_MEASURINGPOINT

SUPER_SESSION_CHAIN

WARRANTY

Defense Disconnected Con guration Data Report (DFS_DIS_DISTRIBUTE)

As described in the chapter System Setup, the report Defense Disconnected Con guration Data Report
(DFS_DIS_DISTRIBUTE) is required for the distribution of the following data:

Local Con guration Data

Individual Tables

Business Objects

A background job with a variant for each of the three types of data selection must be scheduled in the central system to control
the continued data synchronization.

The Initial Data Distribution check box is used for data distribution during the system setup phase, whilst the date and time
range enable the latest data changes to be distributed during the speci ed time frame, in alignment with the scheduling
frequency/interval of the system job.

Offline/Online Connectivity
This is a concept for sending data between the central system and remote server, which ensures that data is only sent if a
con rmation is received from these systems about the readiness to receive data.

Data synchronization should only start once the con rmation about the readiness to receive data has been received.

Data synchronization should be stopped if the central system or remote server is not ready.

The table /ISDFPS/ALE_STAT is used to store the actual system status details.

You can update this table with the system status details by executing the DFPS report or transaction shown below
manually.

Reports and Transactions to Update Connectivity Status

Report Transaction

/ISDFPS/ALE_SET_SYSTEM_OFFLINE /ISDFPS/SET_OFFLINE

/ISDFPS/ALE_SET_SYSTEM_ONLINE /ISDFPS/SET_ONLINE

These reports can be executed in both the central and remote system.

If CON_MODE is OFFLINE, queue processing is stopped.

If CON_MODE is ONLINE, the queues can be processed using the report /SMFND/IBQ_TRANS_PROC_PROG. This report can be
run as a batch job to process unprocessed queues.

System Decommissioning
This is custom documentation. For more information, please visit the SAP Help Portal 20
 7/10/2024
The system decommissioning is the third phase in the lifecycle of a remote server after the system setup and the system
operation. In this phase, for example, it must be ensured that all data and change protection has been re-distributed from the
remote server to the central system, and the delta distribution from the central system to the remote server has been stopped
before the remote server can be physically removed from the overall system landscape.

Subscription Rollback
A system landscape administrator may require the option to perform different activities related to the rollback of subscriptions,
which involves re-distributing ownership and change protection from the remote server to the central system, stopping further
data distribution between the remote server and the central system, and deleting the subscription in the central system.

The following options exist when using the subscription rollback report:

Subscription rollback mode:

Subscription: The rollback steps are performed for a single subscription while connected to the remote server.

System: The rollback steps are performed for all subscriptions related to the speci ed remote server, while connected to
the remote server.

Emergency: The rollback steps are performed for all subscriptions related to the speci ed remote server, even if there is
no connectivity from the central system to the remote server.

Business example: The remote server has been lost or destroyed; therefore, the data ownership must be made available
in the central system and any kind of data distribution must be stopped.

Rollback steps:

Recall ownership: Transfer ownership and change protection for relevant data from the remote server back to the
central system. Stop data distribution from the central system to the remote server.

Delete subscription and MAIF: Delete the relevant subscription-related MAIF table entries and the relevant
subscriptions from the central system.

Transaction: DFS_SUBS_ROLLBACK

System Architecture and Runtime Optimization

While many features regarding system architecture and runtime optimizations are automatically available and integrated in the
system, this chapter points out speci c topics that may be directly visible and therefore relevant to users of the solution.

Conditional Processing
To ensure consistent data distribution between the central system and a remote server, several requirements regarding the
distribution of the outbound and inbound queues have to be ful lled and multiple checks need to be in place.

This can lead to messages in the queue distribution logs explaining why it may not have been possible to successfully distribute
a queue at a certain point in time.

The following features are available with conditional processing:

Connectivity check:

This is custom documentation. For more information, please visit the SAP Help Portal 21
 7/10/2024
Before a queue is sent, the connectivity to the target system is checked and the queue is handled according to the
result.

Ensuring completion of initial data distribution before delta distribution:

Delta distribution of a data synchronization cannot start until the initial data distribution using the subscription has been
completed successfully, including the data checkout.

Sequencing of delta distribution queues:

During the delta distribution, conditional processing ensures that queues for the same object type and key are
processed in the correct order to avoid creating inconsistent data.

Sequencing of initial data distribution queues:

During the initial data distribution using the subscription, conditional processing ensures that queues are processed in
the correct order observing any object dependencies between the queues.

Queue reprocessing:

Queues with an error status stop the data synchronization. Reprocessing provides the option to resend the data after
the cause of the error has been resolved in the sending system.

MAIF Con guration for SAP S/4HANA Defense & Security

Mobile Application Con guration

The mobile application provides a shell that references the complete MAIF con guration content that is delivered for the
remote server for the SAP S/4HANA Defense & Security solution.

The mobile application con guration can be accessed in an SAP S/4 HANA system with the transaction
/SYCLO/CONFIGPANEL.

For more information see Mobile Application Con guration.

Change Detection Settings

Change detection settings are used to de ne and con gure how the mobile application, such as the remote server for the SAP
S/4HANA Defense & Security solution, communicates with SAP and the object tables found in the SAP system.

The following areas are used to con gure backend change detection:

Exchange Object Con guration: Change detection rules for SAP data objects, such as leading data and transaction data,
which are de ned for each mobile application.

EFI Assignment: An enhancement framework implementation trigger that is assigned to exchange objects.

You can nd these areas under Mobile Application Con guration Change Detection Settings . To nd out how to open the
Mobile Application Con guration, see Mobile Application Con guration.

Exchange Framework Integration Settings

This is custom documentation. For more information, please visit the SAP Help Portal 22
 7/10/2024
The exchange framework integration (EFI) is the piece of code that is triggered if a CUD (create, update, delete) operation is
performed for the business objects. The EFI is attached to the saving of the business objects.

From the MAIF con guration panel, navigate to the following path for the creation of an EFI assignment: Mobile Application
Con guration Change Detection Settings EFI Assignment .

The EFI collects before and after images of data in an SAP object that was created, modi ed, or deleted. The EFI then hands
those images to the exchange object, which continues the data processing.

Navigate to the follwing path on the MAIF con guration panel for EFI handler creation: Mobile Application Integration
Framework Con guration Change Detection Settings EFI Assignment . To nd out how to open the Mobile Application
Integration Framework Con guration, see Mobile Application Con guration.

Select the mobile application under Mobile Application Filter.

Select Enhancement Implementation Include, for example /MERP/EFI_MM.

Enhancement Implementation Include indicates the EFI events that are reused and created independently for the SAP
S/4HANA Defense & Security solution.

The namespaces /MERP/ and /SMERP/ include the EFI event handlers that are reused without alteration from the MAIF
standard, and IS_S4DFS_EXCHG_MNT includes event handlers for maintenance that are developed by the defense industry in
SAP S/4HANA.

IS_S4DFS_EXCHG_SUP includes event handlers for supply that are developed by the defense industry in SAP S/4HANA.

IS_S4DFS_MDO_COMMON_FDN includes event handlers for common functions that are developed by the defense industry in
SAP S/4HANA, for example assignments, force elements, and so on.

To create customer-speci c EFI event handlers, follow the steps below:

1. Enter the mobile application created in the mobile application con guration here in the Mobile Application Filter and
choose Create.

Mobile Application Integration Framework Con guration Change Detection Settings EFI Assignment

Select the mobile application under Mobile Application Filter and click on Create.

2. The Enhancement Implementation Includes shown on the left above are the packages that are determined based on the
EFI includes. On the General tab, enter the data for the EFI Type and EFI Event Handler.

Mobile Application Con guration Change Detection Settings EFI Assignment Mobile Application Filter (Select
Mobile Application) Create General .

3. On the General tab, enter the data for the EFI Type and EFI Event Handler.

4. On the Assignment tab, choose Add, provide the highlighted information, and save.

Mobile Application Con guration Change Detection Settings EFI Assignment Mobile Application Filter (Select
Mobile Application) Click on Create Assignment .

5. Choose Add, and provide the following details under Assignment Detail:

Mobile Application: Select the mobile application.

Exchange Object: Select the required object from the listed options.

Exchange Object Desc.: Provide suitable description to exchange object.

ExchObject Handler: Provide exchange object handler.

This is custom documentation. For more information, please visit the SAP Help Portal 23
 7/10/2024
Active Flag: Mark the active ag as Yes.

6. Click on Save.

For generic details see EFI Assignment.

Exchange Object Con guration

The exchange object exchanges the information between the exchange framework integration (EFI) and the mobile data object
(MDO).

Navigate to the following path for a new exchange object creation con guration: Mobile Application Integration Framework
Con guration Change Detection Settings Exchange Object Con guration . To nd out how to open the Mobile Application
Integration Framework Con guration, see Mobile Application Con guration.

A corresponding exchange object con guration is created for every mobile data object. Please note that every exchange object
needs a corresponding handler class before it can be created.

The exchange handlers starting with the namespace /MERP/ are reused from the MAIF platform and all defense-speci c
handlers follow the naming convention CL_DFS_XX.

Exchange handlers are also classi ed based on the area and this is re ected in the naming convention used here. The pre x
DFS_CMN is used for common handlers, DFS_MM for supply handlers, and DFS_PM for maintenance handlers.

Please note that the following tabs are currently not in use for the defense con guration and can therefore be ignored during
the con guration:

Data Segment Settings

Linkage Settings

Push Settings

Table to be updated

For more information, see Exchange Object Con guration.

Inbound Transaction Management Settings

Inbound transaction management consists of the following key concepts:

Inbound transaction queue con guration for the mobile application

BAPI wrapper enablement for inbound transaction management

Inbound transaction processing and lifecycle

Inbound transaction monitoring and administration

Security for inbound transaction management

Navigate to the following path for the inbound transaction management settings: Mobile Application Integration Framework
Con guration Transaction Management Setting Inbound Transaction Queue De nition . To nd out how to open the
Mobile Application Integration Framework Con guration, see Mobile Application Con guration.

This is custom documentation. For more information, please visit the SAP Help Portal 24
 7/10/2024

Inbound Transaction Queue Con guration

Inbound Transaction Queue

Inbound transaction management must be enabled for the mobile application.

The inbound transaction queue is con gured using the inbound transaction queue de nition.

It de nes the types of transactions that can be checked into the queue, and the way in which transactions are managed
and processed.

The inbound transaction queue is mobile-application-speci c.

Multiple standard inbound transaction queues can be de ned for each application. Optionally, a single inbound
transaction queue can be designated as the default inbound queue for the mobile application.

The standard inbound transaction queue can only accept speci c types of transactions based on the queue assignment
settings.

The default inbound queue for the mobile application can accept any types of inbound transactions to which no standard
inbound transaction queue is assigned.

Transaction Queue Assignment

To be able to process an inbound transaction asynchronously, an inbound transaction must be assigned to an inbound
queue. This assignment is based on the technical object or interface that generates the transaction.

The BAPI Wrapper is the only type of technical object or interface supported at this time.

A list of accepted BAPI wrappers should be de ned for each standard inbound transaction queue.

The BAPI wrappers list is not required for the default inbound queue in the mobile application.

In addition to BAPI wrapper restrictions, additional transaction attributes, such as the transaction object type, object
group, and object group 1 can also be de ned as criteria for the queue assignment.

Transaction Queue Handler

A transaction queue handler must be assigned to an inbound transaction queue.

The transaction queue handler provides the technical implementation that manages inbound queue-related tasks, such
as transaction input data parsing, the transaction check-in process, transaction check-out/edit process, transaction
cancellation, transaction approval, transaction key mapping, and transaction processing.

All inbound queue handlers must be sub-classed from the queue handler base class
/SMFND/CL_IBQ_INBQUEUE_MGR_ABS.

A general purpose queue handler /SMFND/CL_INB_Q_MGR_STD is provided to support standard inbound queue tasks.
A specialized inbound queue handler can be developed to handle object type-speci c inbound queue requirements, such
as key-mapping, approval, processing and so on.

BAPI Wrapper
To support inbound transaction management, the following optional parameters must also be de ned for the BAPI wrapper
based on the Mobile Application Integration Framework protocol:

This is custom documentation. For more information, please visit the SAP Help Portal 25
 7/10/2024
Table Parameter IT_TRANSACTION_REQ_INFO, type /SMFND/IBQ_TRANS_REQ_INFO_TAB.

This is an input parameter and must be populated by the calling application.

Table Parameter ET_TRANSACTION_REQ_STATUS, type /SMFND/IBQ_TRANS_REQ_STA_TAB.

This is an output parameter. It returns the inbound transaction status information after a transaction is checked into an
inbound transaction queue.

Inbound Transaction Lifecycle

A transaction in an inbound queue can go through the following phases:

Queue Status

Status Description

NEW Transaction has been checked into the queue, no approval required.

REVIEW Transaction has been checked into the queue, and an approval
work ow is required for the transaction that was checked in.

ERROR Transaction has been processed and resulted in an error.

READY Transaction input data has been modi ed and is ready to be

processed again.

CANCEL Transaction has been cancelled. It can no longer be processed and

should be purged.

COMPLETE Transaction has been processed successfully and should be

purged.

Inbound Transaction Check-In

Inbound transaction management must be enabled for a mobile application for any transaction to be checked into an inbound
queue.

The check-in mode setting in the inbound queue con guration determines how eligible transactions can be checked into a
queue. An eligible transaction is a transaction for which a queue assignment is de ned.

Always Check-In: An eligible transaction is automatically checked into the queue without rst being processed
synchronously.

Dependent Transaction Only: An eligible transaction is only checked into the queue without rst being processed
synchronously if its dependent transactions have already been checked into a queue and have not been processed.
Otherwise, the transaction is processed synchronously.

Error Processing Only: An eligible transaction is rst processed synchronously. The transaction is only checked into the
queue if synchronous processing returns errors.

Synchronous or Asynchronous Processing by the User

Users running the same mobile application can choose between synchronous or asynchronous transaction processing
individually. If you enable the user parameter requirement for the check-in mode, only users with the matching user parameter
ID and activation token value in their SAP user pro le can use inbound transaction processing.

This is custom documentation. For more information, please visit the SAP Help Portal 26
 7/10/2024

Inbound Transaction Approval Work ow

If the approval work ow is activated for an inbound queue, any transactions checked into the queue must be reviewed and
approved before they can be processed. Launch the transaction inspector tool from the Inbound Transaction Monitor to review
and approve any transaction.

An expiration time can be assigned to an inbound transaction. Expired transactions can no longer be processed and should be
purged.

Con ict Resolution

Several options are available for con ict resolution, but in the case of the remote server, we need to capture all changes made,
and recommend selecting Last In Win. The SAP object is posted with the changes in the inbound transaction.

Error Handling, Reprocessing, and Processing History

The transaction processing history with return info is captured automatically by the inbound queue handler and saved for
subsequent review. If an error occurs when an inbound transaction is posted, error messages are also captured as part of the
processing history.

The inbound transaction monitor tool is provided to view the transaction processing history.

Transactions that contain errors can be processed again or edited.

Inbound Queue Authorization

An authorization check is important for the inbound queue process. Speci c authorizations can be de ned for common inbound
queue activities, such as transaction check-out/edit, transaction approval, transaction cancellation, transaction processing, and
transaction deletion.

The authorization check is handled automatically by the inbound queue handler.

Inbound Queue Monitor and Transaction Inspector

The inbound monitor is the central tool provided to monitor and manage any inbound transaction in an inbound queue. The
Transaction Inspector tool is used to manage a speci c inbound transaction. It is fully integrated in the inbound monitor.

Authorized users can use the central tool to perform the following tasks:

View transaction data

Check-out / edit transaction data

Approve a transaction

Cancel a transaction

Process a transaction

Delete a transaction

Inbound transaction management must be enabled for a mobile application.

This is custom documentation. For more information, please visit the SAP Help Portal 27
 7/10/2024
Navigate to the following path to mark the inbound transaction active: Mobile Application Con guration General Info
Mobile Application Con guration . To nd out how to open the Mobile Application Con guration, see Mobile Application
Con guration.

Select the created mobile application under De ned Mobile Application.

On the General tab, under Inbound Transaction Management click on the Inbound Transaction Active checkbox.

Initial Data Distribution: Order for Initial Master Data Creation

Data Agent
Data agents are the data retrieval con guration required to trigger the data retrieval for the speci c SAP object type. This
means that a data agent exists for every mobile data object.

The data agent is supplied with a handler class, which is then integrated during the data transfer for the objects during the
initial data distribution.

Data agents are primarily used during the initial data distribution.

Navigate to the following path for sample data agent de nition: Mobile Application Con guration Data Staging Settings
Data Agent De nition . To nd out how to open the Mobile Application Con guration, see Mobile Application Con guration.

Select the mobile application from the Mobile Application Filter.

Select any data agent under Data Agent by Mobile App.

Data Store De nition

The data store de nes the replication scenarios that are used between the systems.

The data store also creates the linkage between the data agents created in the previous step and the scheduler functionality.

This also de nes the sequence in which the data is loaded into the outbound queues during the initial data distribution.

This sequence can be de ned on the Agent Assignment tab.

Currently, two data stores are de ned:

Initial data distribution (DFS_STORE_INITIAL_LOAD)

Change protection (DFS_STORE_CHANGE_PROETCTION)

Navigate to the following path to maintain the initial load data store and its corresponding agents assigned with the sequence:

1. Mobile Application Con guration Data Staging Settings Data Store De nition . To nd out how to open the
Mobile Application Con guration, see Mobile Application Con guration.

2. Select the mobile application from the Mobile Application Filter.

3. Under the Data Staging by Mobile App options select DFS_STORE_INITIAL_LOAD.

4. Navigate to the Agent Assignment tab. Click on the Create button and provide the following details:

This is custom documentation. For more information, please visit the SAP Help Portal 28
 7/10/2024
Data Store ID: DFS_STORE_INITIAL_LOAD

Mobile Application: <Provide the mobile application>

Data Agent ID: <Data Agent ID>

Data Segment ID: <Data Segement ID>

Table Mappings: <Provide table mappings as shown below>

Assignment No. Data Segment ID Data Agent ID Parameter Name

002 WORKORDER DFS_AGENT_WORKORER

003 WORKCENTER DFS_AGENT_WORKCENTER

Mobile Data Object Con guration

Mobile data objects represent the fundamental objects in MAIF, which contain the logic used to replicate data from the central
to the remote system and vice versa.

The data object type Synchronization MDO is mainly used to transfer data between two SAP systems.

MDOs have an internal integration with the exchange object. This means that whenever changes are made to the SAP business
objects, the corresponding EFI event attached to the SAP Business objects is triggered. These events are generally hooked in
the CUD (Create, Update, Delete) methods for the business objects. These events transfer the information about changes
related to the before and after image for the business object. These are consumed by the corresponding exchange objects.

The main method that is triggered during the MDO synchronization is EXEC_SYNCHRONIZE.

BAPI Wrapper Con guration

The BAPI wrapper layer provides a consistent way of exposing business logic and data from the SAP system to external mobile
applications. The BAPI wrappers are decoupled from the business logic in SAP, making them easy to recon gure or customize.

Please note that the BAPI wrappers are identical for the initial data distribution and the delta distribution. The BAPI wrapper is
essentially used as a data carrier structure from one system to another system and is mass enabled from a structural point of
view.

To view the sample BAPI Wrapper content, navigate to the following path: Mobile Application Con guration RFC Channel
Integration Settings BAPI Wrapper Con guration . Select a BAPI wrapper in theBAPI Wrapper List and open the General
tab. To nd out how to open the Mobile Application Con guration, see Mobile Application Con guration.

Push Scenario De nition

Push scenarios de ne the trigger conditions and type of data that needs to be synchronized to the remote servers from the
central system and from the remote servers to the central system.

The remote server and the central system are used to send application data or push noti cations to the other SAP systems or
remote servers if certain trigger conditions are met. If these trigger conditions are not met, the remote server does not initiate
the synchronization request.

This is custom documentation. For more information, please visit the SAP Help Portal 29
 7/10/2024
For more information see Push Scenario De nition.

Data Management in Defense & Security

In this section, you can nd the functions available for managing your data.

Related Information
Data Management in SAP S/4HANA

Data Archiving in Defense & Security

Archiving Assignments Using DFS_ASSGMT

You can use the archiving object DFS_ASSGMT to archive assignments.

Tables

DFS_ASSGMT archives data from several tables. To check which tables these are, call up transaction SARA, enter the archiving
object, and choose Database Tables. You can display the relevant tables in the lower part of the screen.

Archiving Classes

DFS_ASSGMT may trigger additional archiving classes to write additional data, such as change documents, to the archive. To
check which classes these are, call up transaction AOBJ, select your archiving object and choose Archiving Classes Used.

Programs

To nd out which programs this archiving object offers, call up transaction AOBJ and double-click on your archiving object.

Prerequisites
The following prerequisites must be ful lled before an assignment can be archived:

Only assignments with the status Deactivated can be archived.

ILM-Related Information for the Archiving Object

You can use this archiving object with the DFS_ASSGMT ILM object as part of SAP Information Lifecycle Management. In
transaction IRMPOL, you can create policies for residence or retention rules, depending on the available policy category. Here
you can also see the available time references and which condition elds exist, and decide which of them shall be used in which
order to de ne your rule structure.

The following condition elds are available:

DFSASSGMTSOURCETYPE

Source Object Category; it can have the following values:

FRC (Force Element)

This is custom documentation. For more information, please visit the SAP Help Portal 30
 7/10/2024
CAP (Capability Code)

POS (Position)

PLC (Platform Code)

DFSASSGMTSTATUSCODE

Individual Status of an Object. The status of the assignment.

DFSASSGMTTYPE

Assignment Category, can include the types stored in the table DFS_ASSGMT_TYPE

DFSCAPABILITYOBJECTID

Capability Object ID

DFSMAINTPLATFORMID

Platform ID

DFSPOSITIONSOURCEID

Position ID

FORCEELEMENTORGSRCEID

Source Force Element

The following time references are available:

VALID_TO

This is the Valid To date assignment.

For more information, see SAP Information Lifecycle Management.

Legal Holds

It is possible to set a legal hold on this archiving object. For more information, see Setting Legal Holds.

De ning Write Variants

When you schedule the archiving run, you must enter an existing variant or create a new one. You can do so in transaction SARA.

A write variant contains the parameters for the assignments that you want to archive.

SAP delivers the following parameters:

Source Object Type:

FRC (Force Element)

CAP (Capability Code)

POS (Position)

PLC (Platform Code)

Force Element / Capability / Platform / Position

This is custom documentation. For more information, please visit the SAP Help Portal 31
 7/10/2024

De ning Read Program Variants

Depending on the source object type selected the following elds are visible on the screen:

Source Object Type:

FRC (Force Element)

CAP (Capability Code)

POS (Position)

PLC (Platform Code)

Force Element / Capability / Platform / Position

Dependencies of DSF_ASSGMT
For information on the archiving session order, see the Network Graphic for your archiving object in transaction SARA under
Goto → Network Graphic.

Displaying Assignments Archived with DFS_ASSGMT

Field catalog name: SAP_DFS_ASSGMT ( DFS: Archive Object Assignment)

Reference Fields:

DFS_ASSGMT DFSASSGMTUUID

DFS_ASSGMT DFSASSGMTSOURCETYPE

DFS_ASSGMT DFSASSGMTTYPE

DFS_ASSGMT FORCEELEMENTORGSRCEID

DFS_ASSGMT DFSMAINTPLATFORMID

DFS_ASSGMT DFSCAPABILITYOBJECTID

DFS_ASSGMT DFSPOSITIONSOURCEID

Infostructure name: SAP_DFS_ASSGMT

This is custom documentation. For more information, please visit the SAP Help Portal 32