Skip to main content

IDOC integration (UBC.idoc)

Intro​

UBC - Unified Backend Connector comes with a component for elegant IDOC processing using UBC technique. This allows to connect IDOCs with any process configured in UBC. UBC.idoc is the connection between SAP standard IDOC and the UBC process: started with UBC.flow inlc. message exchange and monitoring within UBC.io.

Customizing​

The IDOC types have to be linked to a specific business object first and this combination message type/IDOC type/extension has to be unique from a business object perspective, as the object implementation is determined by these attributes. See transaction /UBC/CUSTOMIZING -> Business object configuration.

IDOC basic type configuration
The IDOC basic type (and extension) has to be specified for this object type at the top level. At the second level, all message types will be assigned which results in this object.
IDOC message type link
Optional a versioning mechanism can be applied at "object type" level to a custom object. Making use of this mechanism allows to make structural changes without affecting previous versions. The default IDOC category handler always chooses the latest version.

Development​

IDOC type generation​

Use transaction /UBC/IDOC_STRUCT_GEN to generate ABAP types (for usage in public sections of classes/interfaces) for an IDOC. You can then convert any IDOC (EDIDC, EDIDD) to an ABAP type (and back) using converter class /UBC/CL_IDOC_CONVERTER. This is rather a generic approach and can be used in any process within SAP! It does not need a UBC business object. Use it wherever you like to simplify development a lot!

success

No need to struggle with EDIDD-SDATA(CHAR1000) conversions, IDOC hierarchies and repeated segments anymore.

Here you can see an example of a generated type for an ORDERS05 IDOC type. Example ABAP type

Please find the following snippets to convert IDOC's data back and forth.

"the type was previously generated using /UBC/IDOC_STRUCT_GEN
data(ls_orders05) = value s_orders05( ).

"read IDOC - get well known EDIDC/EDIDD
data(ls_edidc) = value edidc( ).
data(lt_edidd) = value edidd_tt( ).
call function 'IDOC_READ_COMPLETELY'
  exporting
    document_number = '0000000000004711'
  importing
    idoc_control    = ls_edidc
  tables
    int_edidd       = lt_edidd
  exceptions
    others          = 1.
if sy-subrc <> 0.
  raise exception type /ubc/cx_core using message.
endif.

"convert the IDOC data to the concrete type
/ubc/cl_idoc_converter=>get_instance( )->serialize(
  exporting
    is_edidc  = /ubc/cl_idoc_converter=>get_instance( )->convert_control_int_to_ext( ls_edidc )
    it_edidd  = lt_edidd
  importing
    ev_result = ls_orders05 ).

"process the IDOC using the structured type
ls_orders05-data-e1edk01-brgew += 1.

"EXAMPLE to convert the type back to EDIDC/EDIDD
/ubc/cl_idoc_converter=>get_instance( )->deserialize(
  exporting
    ir_idoc  = ref #( ls_orders05 )
  importing
    es_edidc = data(ls_edidc_new)
    et_edidd = data(lt_edidd_new) ).

Handler​

It is important to specify a handler that inherits from /UBC/CL_BO_IDOC or implements at least the interface /UBC/IF_BO_IDOC for a custom outbound process.

Outbound​

UBC integrates seamlessly in the SAP-standard outbound mechanism. This means, up to step "transmit IDOC to party xy" – it is a standard procedure. Short summary:

  • configure EDI output message for the document to be transmitted
    EDI output message
  • configure partner determination (WE20) – outbound for specific partner
    Partner determination
  • now comes the UBC specific part and trigger when specifying the receiver port within the partner determination. Usually, a port is used for a PI or any other direct connections. Specify /UBC/IDOC to trigger UBC.
    Port /UBC/IDOC
    This enables UBC to link the IDOC to the previously configured UBC object (by looking up message type, basic type, extension) and calling the method /UBC/IF_BO_IDOC->PROCESS_PORT.
info

Of course, the determination does not necessarily need to be partner-specific. The partner determination can be modelled once too, but this is just SAP standard:
no specific partner
no specific partner

Standard implementation /UBC/CL_BO_IDOC​

When using standard implementation /UBC/CL_BO_IDOC, a new outbound workflow will be started. By default, a workflow is started for every registered proxy. If more than one proxy was registered, the company code can be used to distigunish which the proxy was registered. Most of the documents in SAP correlate to a specific company code. If such a distinction is needed, implement behavior in method GET_COMPANY_CODE_FOR_RESTR. If the company code determination was implemented, the registered proxy for the specific company code will be automatically determined. Others will be ignored. If, however, a different behavior with respect to the determination of the proxy is required, overwrite the method CHOOSE_PROXIES_FOR_IDOC.

Inbound​

Usually UBC only triggers the inbound of documents withing UBC processes. Thus there can be no generic description made here. For simplicity reasons we recommend using just one partner definition LS /UBC/PROXY for those cases and make UBC post the IDOC to this generic definition, requiring to do the custom mapping before creation of the IDOC. Usually the configuration/process code for this IDOC remains untouched and starts just the SAP standard processing.
Inbound /UBC/PROXY