Having finally figured out what the difference between a message type and a basic type is in SAP IDocs, another question came to my mind: which IDoc basic types are compatible?

Basic Type Relations

“Which IDoc basic types are compatible” might not seem like a terribly relevant question, since the fields in partner profile seem to nudge us towards the idea that basic types and their extensions are compatible and other combinations need not be considered:

But this completely ignores the observation that, for example, four different basic types exist for classification message type CLSMAS (CLSMAS01 through CLSMAS04) and will all be distributed to receivers, hopefully by not creating and distributing each and every one individually. These basic types represent the information referred to by message type CLSMAS but differ in what segments they include. The key observation is how these segments vary: later basic types (ie. the ones with greater numbers) add segments but never alter the previously defined ones.

Compared to CLSMAS01, CLSMAS02 adds a few new segments (added segments have white background):

The new segments are optional and the basic type also includes all segments from CLSMAS01.

Adding new segments without altering the existing ones is also the rule enforced when defining an extension of a basic type. This makes sense when thought in the context of subclassing: the subclass can strengthen the postconditions but cannot weaken them – ie. the compatible basic type can include more data segments but it cannot skimp on any of the previously defined ones. By adhering to these rules (more or less the Liskov substitution principle), the new basic/extended type (ie. the subclass) can function as the superclass and still support new features.

It turns out that another type of relation exists between basic types: the predecessor/successor -relationship.

When successors are created, the new segments cannot be mandatory and the attributes of existing segments cannot be changed:

This is different from how extensions work, since new segments can be defined as mandatory in extensions. The result of this is that successors have weaker technical guarantees as to their structure: since every new segment after the initial basic type is technically optional, a message is valid regardless of which of the new segments are included or missing. In other words, the mandatory fields in the initial basic type are the only strong guarantees a message type implies. Later basic types represent these segments and then some, or maybe not.

In contrast, since segments in an extension can be mandatory, a message can be invalid if one or more of these segments are missing. An extension then provides a stronger guarantee about the structure of a message.

Distributing Compatible Basic Types

Strict compatibility is enforced for basic types that are part of a predecessor/successor relation. This means that a structurally valid successor is always also a structurally valid predecessor, and the former can be transformed into the latter by simply dropping any extra segments (this also seems to imply that a structurally valid predecessor is always also a valid successor, since every added segments is technically optional).

While this makes sense on paper, it doesn’t automatically mean that SAP will try to convert from one basic type to another when an IDoc is distributed. That would mean that when MASTER_IDOC_DISTRIBUTE is invoked with a specific basic type, SAP will try to automatically convert the message to the basic type/extended type defined in a given partner profile. MASTER_IDOC_DISTRIBUTE could then be invoked with the maximal basic type (ie. the latest one) and all parties interested in the message type (in case of ALE distribution) would then receive an IDoc with the basic type specified in their partner profiles. Otherwise the sender would be required to construct all basic types and to distribute them one after another, becoming a needless burden (given the strict compatibility requirement among related basic types).

And it turns out, that’s exactly how the MASTER_IDOC_DISTRIBUTE function module works: it automatically converts between basic types according to what is specified in the partner profile.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

DATA(ls_master_idoc_control) = VALUE edidc( mestyp = 'CLSMAS' idoctp = 'ZCLSMAS02' ).

DATA(lt_master_idoc_data) = VALUE edidd_tt(
  ( segnum = '000001' segnam = 'E1KLAHM' )
  ( segnum = '000002' segnam = 'E1KSMLM' psgnum = '000001' )
  ( segnum = '000003' segnam = 'E1CUKB3' psgnum = '000001' )
  ( segnum = '000004' segnam = 'ZXTRSEG' psgnum = '000001' )
).

DATA lt_distributed_idoc TYPE STANDARD TABLE OF edidc.

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
  EXPORTING
    master_idoc_control            = ls_master_idoc_control
  tables
    communication_idoc_control     = lt_distributed_idoc
    master_idoc_data               = lt_master_idoc_data
  exceptions
    error_in_idoc_control          = 1
    error_writing_idoc_status      = 2
    error_in_idoc_data             = 3
    sending_logical_system_unknown = 4
    others                         = 5.

IF sy-subrc = 0.
  COMMIT WORK.
ENDIF.

In the above snippet, ZCLMAS02 is a copy of CLSMAS02 with one extra, mandatory segment ZXTRSEG. It is linked to CLSMAS message type in WE82. In the ALE distribution model, logical systems MAGI1 and MAGI2 both subscribe to CLSMAS messages.

After running the code, the end result will be the following:

Ie. no system received the ZCLMAS02 basic type, but instead the compatible basic types CLSMAS02 and CLSMAS01.

Custom “Successors”

It is not possible to define a successor for a basic type defined by SAP (which makes sense). But this does not mean that it is not possible to create a compatible basic type: since the notion of “compatibility” has nothing to do with predecessor/successor -relation, but is rather just defined by the presence of the right segments, in the right hierarchical configuration and adhering to the right limits of occurence. This means that, like in the above ABAP snippet, any two basic types can be compatible; it’s just that SAP tools will not enforce compatibility like is the case with predecessor/successor types.