Skip to main content

I/O Monitoring (UBC.io)

Intro​

UBC - Unified Backend Connector comes with a component for I/O monitoring/processing, which is a tool and framework for comprehensive interface monitoring from and into the SAP system​ - single entry point! A few key facts:

  • Monitoring, restarting, editing of various messages without environment system involvement clearly arranged in the cockpit​
  • Logging of changes and runs
  • Auto restart
  • Logical chaining of processes via queueing​
  • Structured message search and display
  • Alerting – workflow integration
  • Easy to integrate: Pre-delivered templates
  • No additional licenses needed​ - integrated into the on-premise system

Overview

Monitoring and error handling​

Basically there are 2 Monitoring and error handling transactions for getting an holistic overview of all the messages within the system. UBC.io is organized by "interfaces", which are basically a grouping of one to many technical interfaces to a "logical" unit (e.g. all MES interfaces related to a production order). Each interface can have attributes which are mapped from the message payload to an index table for a structured search and overview in a result list.

I/O detail monitor /UBC/IO​

This transaction is for a structure search for chosen payload attributes, for detailed analysis and for all error handling tasks. First you choose one or many interfaces to select for messages and further restrict the selection screen (which is an intersection of all available indexed fields and eventually Multi index fields). You can select e.g.:

  • for messages of material 4711 which were sent today
  • for messages in an error state
  • ...

Selection screen

By hitting Execute(F8) the result list will be displayed. As in the selection screen, it is the intersection of all available indexed fields.

Depending on the interface processing mode (asynchronous/synchronous) following options are available:

  • editing messages (asynchronous only) Basically the message will be copied, the old message will be set to status OBS and the new message will be processed, depending on the processing type
  • restarting of messages in an error state (asynchronous only)
    tip

    If the User which triggers the Restart is different from the User which initially triggered the message, the following applies:

    • the initial user processes the transaction (as the bgRFC unit remains)
    • the admin data for the message shows the user which restarted the message as "last changed by"
    • in the log you will see, which user processed the transaction. This log message is only shown, if the users (Restart vs. Processing) are different.
  • acknowledgment of messages in an error state (asynchronous only)
  • copying messages for testing

(Actions are available for multi selection) Selection screen
The screen has basically 4 areas:

  • result list (top left) with alle the indexed fields, actions, ... Click on the message number to select a message and view the details. Selecting a message shows the other parts of the screen.
  • application log (top right) Processing log of a message including all the actions happened.
  • Runs (bottom left) Showing all the runs of a message. Basically a "Restart" starts a new run.
  • Message payload (bottom right) Grid display of all the contents of the message including the options to view and download as JSON

Message status​

The following is a list of all possible status a message can have:

  • ERROR The message is in an error state and waits for action (restart, acknowledgment)
  • ACK A message in status ERROR was acknowledged.
  • SUCC The message was successfully processed, without any errors.
  • OBS The message was edited. The old message was saved in status OBS for research reasons. The new message points to the old message.
  • COPY The message was copied and is ready for processing.
  • QUEUE The message was saved and waits for processing, which will start as soon as system resources are available or if a predecessor exists, the predecessor was processed successfully/acknowledged.
  • PEND The message is currently processing.
  • READY The message is ready for being processed, but needs a confirmation by a user which needs to release it by selecting "Restart" in the monitor (only for processing type Manual processing)

Processing options (Queue type)​

Both asynchronous or synchronous processing of messages is available.

Synchronous processing​

The message will be processed synchronously. It's just like any other function module call and behaves the same, the caller does not need to consider anything special. Synchronous processing is usually chosen for logging reasons only, restart of such a message does not make much sense and is not possible! If needed for troubleshooting/debugging reasons, copy the message.

Asynchronous processing​

No queue (transactional)​

Messages will be processed in arbitrary order. Choose one of the options below if the messages does not belong to each other.

Automatic processing​

Processing of the message starts immediatly just right after resources are available asynchronously.

Manual processing​

New messages saved in status READY. The processing of the messages have to be triggered by going to the I/O monitoring transaction /UBC/IO and restarting a message in status READY. The processing of the message starts then immediatly just right after resources are available asynchronously.

Queue (all asychronous processing)​

Messages will be processed in a well defined order. Choose one of the options below if the messages are in any relation to each other within a Queue. The Sequence is important! If the first message in a queue gets stuck by an error, the queue gets blocked. The following entries will not be processed until the error of the first message gets resolved (by acknowledge or restart). The Queue key can be freely defined (up to 40 characters in total) by concatenating either parts of the index table (which was mapped out of the message payload) or literals (to further distinguish). For example, messages contains a material needs to be posted in a defined order to prevent locking and errors. The following configuration constructs a key like MATERIAL_<<matnr>>. Best practice: use literals first to distinguish the type of object to queue for (in this example: MATERIAL). The queue key is globally valid across your interfaces. Queue key configuration

warning

Every queue key have to match to a prefix configured in your target bgRFC destination. See below in section bgRFC configuration

By creation timestamp​

The entries within a Queue are ordered by Creation Timestamp (UTC Long) of the message. First in - First out!

By message payload index​

You need to additionally specify a field of your index table where the external Index is located - mapped from the message payload. An external index is a Integer Number starting with 1 without any gaps. The external index is determined by the sender system and sent within the message payload. This technique is needed for example, if you have a strict processing order, but a middleware in place and you cannot ensure that messages which need to be processed first are also sent first. Then your sender system needs to generate the external index starting with 1. Let's construct an example:

5 Messages will be sent in arbitrary order, all allocated to the same queue:

  • Message with Index 1
  • Message with Index 3
  • Message with Index 2
  • Message with Index 5
  • Message with Index 4

Using external Index ensures to process the Messages in a correct order:

  • Message with Index 1
  • Message with Index 2
  • Message with Index 3
  • Message with Index 4
  • Message with Index 5

The processing of the next message in a queue waits until it was written to the queue and unlocks the processing.

Queue monitor /UBC/IO_QUEUE​

This transaction basically is an overview of all messages which are currently organized by a Queue. You can see the reasons why messages are waiting (predecessors) and of course details. You can jump to the monitor by selecting the messages and click on "monitor".
Queue monitor

Development​

This step contains all the information needed for developing an new interface, from Customizing to development.

Customizing​

Interfaces​

Start with transaction /UBC/IO_C with defining new interfaces. Interface definition

  • Interface name and description As mentioned, UBC.io is organized by interfaces where many technical interfaces referring to the same (e.g. MES interfaces to a production order) are grouped logically. Interface name is unique, description can be translated.
  • Index table An index table is intended to hold adminstrative data for a message like "status", "creation data", ... It's an customer created table with a fixed signature (see templates) enabling to add custom fields in a dedicated include and map message payload data to an index table. In the generic monitoring transactions, you are enabled to search/filter for all the fields in an index table. Furthermore you can define "Jumps" to transactions using custom logic in BADIs. If no index table is specified, a default index table is used.
  • Queue type (see Processing options)
  • bgRFC destination If the chosen queue type is asynchronous, you have to define a valid bgRFC inbound destination where the entries for an interface will be processed. (see system setup)
  • Message Index If the chosen queue type is Message payload index you have to specify the name of the field in your index table where the external index is stored to queue for.
  • Mapping class (optional) The given mapping class can override the standard behavior, which basically applies the customizing field mapping. The mapping class has to implement the interface /C09/IF_CIO_MAP_IDX_SINGLE. For implementation examples, see default implementation /C09/CL_CIO_MAP_IDX_SINGLE. If the field is empty, the default implementation takes place, applying the customizing. Overriding this behavior makes sense when there is some complex calculation logic which cannot be defined by customizing.
  • Function class (optional) I/O monitoring implementation, inheriting from /C09/CL_CIO_LIST to override some default behaviour if needed. If not specified, the default implementation takes place. Not needed in most of the cases. Prefer using BADIs if possible.
Assign technical interfaces to UBC.io interface​

Currently, only function modules are supported for technical interfaces managed by UBC.io to keep the complexity low. Most of the requirements can be fulfilled using this approach. This is subject to change and may be enhanced if needed. Please get in touch with us! Specify a function module name as a top level entry for the assignment to an interface. Please note that the function module has to embed to simple calls at the begin and end to be ready for usage within UBC.io (see also Implementation).

Field mapping​

The field mapping is for basically 2 purposes:

  • mapping of message payload to index table fields For searching/indexing/overview reasons
  • specify where the functional messages are located to map to the application log of a message. This step is important in order to determine wether a message was erroneous or not (containing message of type E/A/X) Field mapping
  • Order Mapping order, just increment in customizing.
  • Field path
    Mapping path to specific field in payload:
    • deeply navigating: structures/tables separated by -
    • use search help (F4) for navigating within your payload (if type is known statically)
    • supports [] for tables
      • access specific index by just specifying the index, e.g. [1]
      • access by specific fields in table (only supporting AND condition), e.g. [fieldA=ABC and fieldB='']
    • supports substring functionality for elements, e.g. fieldA+1(1) (Offset 1, Length 1 of content in fieldA)
  • Fieldname table
    Fieldname in index table, custom include. Have to be empty, if messages are mapped.
  • contains messages
    Tick if specifying messages entry for mapping to application log.
  • optional
    As per default, all mappings which cannot be successfully executed (missing table entry, ...) results in an error (writing to application log, message in status ERROR). Tick this checkbox to simply leave the target empty.
Multi steps (LUWs)​

An inbound interface can have more than one LUW. For example when dealing with multiple Goods Movements in one interface, you have to commit each goods movement. In order to be restart-able a interface has to consist only of one LUW. (commit or not) To fulfill the above mentioned requirement you can configure "multi steps" interfaces to support more than one LUW, controlled by a single interface (and a top level function module). Please see implementation details, Multi Step Interfaces. Multi steps Customizing
In this scenario your top level function module, entered in section Assign technical interfaces to UBC.io interface, is just acting as a wrapper and/or session initialization module. Each time the message starts processing, first the top level module will be executed and then continued with the step which failed.

  • Step Number
    Key of the table + the defined execution order of the steps. The execution order is:
    1. Top Level function module once at the beginning of a Run
    2. Beginning where the execution last stopped due to an error OR at the begin For every step configured, sorted by order.
  • Function Module name
  • Commit mode
    As no function module should ever contain a COMMIT WORK or ROLLBACK WORK, specify the commit mode after each step.
  • Continue on Error
    Ignore errors in function module, complete step and continue with execution.
  • Restart always
    If a step 10 was completed and 20 fails, on restart step 10 will not be executed again. Except the case that step 10 was marked as "restart always".
Multi Index tables​

Sometimes there are more complex use cases where you would like to search for field values in a table. Imagine having a payload like:

{
  "order_header": {
    "incoterm": "abc",
    "shipTo": 4711
  },
  "order_items": [
    {
      "material": "123",
      "plant": "0001"
    },
    {
      "material": "456",
      "plant": "0002"
    },
    {
      "material": "789",
      "plant": "0003"
    }
  ]
}

You may want to search for messages regarding material "456". As "order_items" is a table, it cannot be mapped to a flat single index table for searching.
This is where "Multi Index tables" comes in. Multi Index table header

  • Multi Index table
    A Multi Index table is intended to have an entry for every line in the specified table It's an customer created table with a fixed signature, see templates: especially copy table /UBC/IO_TTPLMIDX and replace the fields matnr and charge with your custom ones.
    In the generic monitoring transactions, you are enabled to search for all the fields in the multi index table out-of-the-box. Please note that this only applies for the selection screen, as for the result list this does not really make sense.
    warning

    As the Multi Index and Single Index tables are different ones, the results are technically combined with "logical AND". If one entry in the list of "multi index entries" is matching, the message is considered as a match.

  • Base path
    Specify a tabular component withing your actual payload structure. The standard implementation currently only supports tables, not tables in tables.
    You are free to use expressions like item[1]-schedules, but items-schedules is not supported. The last component needs to be a table to considered for the multi index set.
  • Mapping class (optional)
    The given mapping class can override the standard behavior, which basically applies the customizing for the field mapping in the level below. The mapping class has to implement the interface /C09/IF_CIO_MAP_IDX_MULTI. For implementation examples, see default implementation /C09/CL_CIO_MAP_IDX_MULTI. If the field is empty, the default implementation takes place, applying the customizing. Overriding this behavior makes sense when there is some complex calculation logic which cannot be defined by customizing.

field mapping
For details please see section field mapping.
The same applies also here, with the following additions/restrictions:

  • the base path (see above) will get respected, so you will have only elements available for the standard mapping contained in the specified table. field mapping multi index
    (in this example: only elements contained in IT_ITEM specified above, you are free to apply the well known mapping syntax also here)
  • no message mapping to application log in standard
  • all mappings are optional, not throwing any error

Coming back to our initial example, that means we have 4 index table entries in general.

  • 1 for the message itself in the single index table.
  • 3 entries in the Multi Index table

The generic I/O monitor respects the Multi Index entries and adds the fields to the selection screen too.

Queue keys​

Mapping from Index Table Fields and/or Literals to Queue keys. Please consider the following best practice to avoid queue name conflicts: as a queue prefix, always start with the type the queue key stands for. For example: Queue Key Example for Material
You can see that the Queue starts with the literal MATERIAL_ and then adds the material number. A Queue example would be MATERIAL_4711. By default, an alpha conversion is applied to a field value. The queue key will be concatenated according to the given sequence. You are free to add as much fields and literals to your queue key as needed. Just consider the limit of 40 characters in total.

Auto Restart​

First, define a Auto Restart group in View Cluster Entry restart groups. It is for defining the "maximum runs" and wait time between a run.
You have to assign specific combinations of "T100" Message-Id and -Number. As soon as the error of an interface contains a message configured in its Auto Restart group, it will be considered. If an error message is not configured withing the restart group, it will not be considered.
The following applies for the Message Keys:

  • for Message Number, make sure to specify the full key with leading zeros (001 and not 1)
  • you are allowed to use patterns like * and + for Message Class and Number
  • if you leave a field (Message Class or Number) empty, it acts like a * wildcard for those field

For example, you will define the "T100" Message Combination for "Message is locked" and define that the restart can be tried again in 5 minutes for 3 times.
If the material than is locked again, the Message won't be auto restarted again.

Auto Restart Group
Assignment of Messages
Finally the Auto Restart Group needs to be assigned to an Interface Function assignment on level functions in view cluster.

info

Auto restart only makes sense for asynchronous interfaces, as for synchronous the caller usually waits for the response in order to process it. Thus, Auto restart feature only respects asynchronous messages.

Workflow Integration​

The concept for Workflow Integration is just the same as for Auto Restart Groups.

  1. Create a workflow definition and implement the workflow, transaction /C09/CONFLOW_C. Please note that currently, only UBC.flow workflows are supported! See here for detailled and generic product documentation. As this is highly customer specific we cannot provide an out-of-the-box implementation. Please see below for an example as a quick start.
  2. Link the newly created workflow to the interface:
    Starting with Transaction /UBC/IO_CFL_C, create a Workflow Group.
  3. In the view cluster, wwich to mapping groups <> messages assign T100 Message-Id and -Number combination and a target Workflow-Definition-Id to be started. For every matching message in a message run, the target Workflow will be started. mapping groups messages example
info

The workflows will be triggered only if the message is not auto restartable anymore, meaning the max. Retries were reached or auto restart was not configured.
Example use case: Alerting an erroneous message by given message, e.g. "Material is locked".
At a first glance, triggering workflows for alerting seems complicated. But most of the time, it is highly recommended to not just trigger emails. Instead we can just easily use dialog workitems and model more complex workflows if needed. Using workflow approach we can stick to the same procedure and just change some customizing. Start easy (only with mail alerting) and refine the flow.

Example implementation​

In the following, we provide an example implementation of a workflow just triggering an email. See above for linking the workflow definition to the T100 message.

  • Create the workflow definition in /C09/CONFLOW_C

  • Go to Approval steps, and create all possible workflow steps.

    tip

    X0, X1 and X2 are predefined ones and shall always be created.

    Workflow Approval Steps

  • Go to User Status Definition and create user status for involved user groups. Best practice is, to have at least Initiator and Background. Workflow User Status Definition

  • Go to User Status Assignment and assign users to your user groups. Depending on wether you would like to transport the entries, choose the right entry in the view cluster.

    warning

    Make sure to use the one OR the other. Entries in both are not supported.

    Workflow User Status Assignment

  • Define the actual flow by switching to Approval status - control. Always start with X0 and end with X1 or X2.
    Here, the one and only background step does not have any action assigned and results always in OK. The workflow then ends directly after sending the mail. Workflow Approval status - control

  • Optionally define mail settings by switching to Control mail setting. You are free to configure mail hooks by reaching certain results of the step. Workflow Control mail setting Here is an example of the resulting mail: Mail example A few notes:

    • The HTML template /UBC/S17_MAIL_TEMPLATE was used and is delivered with every UBC installation. You are free to use your own HTML mail template. Just upload a new one in transaction SMW0, you may copy from the existing template.
    • The Subject and Text Text-Ids are maintained and translated in transaction SO10. Make use of variables.
      • Subject ZUBC_DEMO_SUBJECT_113 ZUBC_DEMO_SUBJECT_113
      • Text ZUBC_DEMO_ERROR_113 ZUBC_DEMO_ERROR_113

  • Now create a implementation for your workflow by creating a BADI and filtering (!) to your definition. BADI implementation

  • Please find the example ABAP implementation below.

    class zubc_cl_cfl_badi_113 definition
      public
      create public.

      public section.
        interfaces if_badi_interface.
        interfaces /c09/cfl_if_badi_0101.
      protected section.
        methods get_io_attributes
          importing
            iv_instid type /c09/cfl_s01-instid
          exporting
            ev_msg_id type /c09/cio_msgguid
            ev_ifname type /c09/cio_ifname.
        methods get_io_message
          importing
            iv_instid        type /c09/cfl_s01-instid
          returning
            value(ro_result) type ref to /c09/cl_cio_msg.
      private section.
    endclass.


    class zubc_cl_cfl_badi_113 implementation.
      method /c09/cfl_if_badi_0101~execute_default_method.
        " jump to I/O when clicking on linked object
        get_io_attributes( exporting iv_instid = /c09/cfl_cl_workflow_0101=>ms_instances-instance->ms_data-instid
                          importing ev_msg_id = data(lv_msg_id)
                                    ev_ifname = data(lv_ifname) ).
        call function '/C09/CIO_START'
          exporting
            p_skip_se16n = abap_true
            irt_ifname   = value /c09/if_cio=>trt_ifname( ( sign = 'I' option = 'EQ' low = lv_ifname ) )
            irt_msgguid  = value /c09/if_cio=>trt_msgguid( ( sign = 'I' option = 'EQ' low = lv_msg_id ) ).
      endmethod.

      method /c09/cfl_if_badi_0101~get_add_attachments.
        " add link to I/O as Attachment to mail
        get_io_attributes( exporting iv_instid = is_data-instid
                          importing ev_msg_id = data(lv_msg_id)
                                    ev_ifname = data(lv_ifname) ).
        try.
            insert lines of /ubc/cl_tools=>get_instance( )->get_gui_transaction_shortcut(
                iv_name_base   = 'Shortcut'
                iv_transaction = /ubc/if_constants=>mc_cio-transaction_single-tcode
                it_parameter   = value #(
                    ( name = /ubc/if_constants=>mc_cio-transaction_single-parameters-message_id value = lv_msg_id )
                    ( name = /ubc/if_constants=>mc_cio-transaction_single-parameters-interface_name value = lv_ifname ) ) )
                  into table ct_attachment.
          catch /ubc/cx_core.
        endtry.
      endmethod.

      method /c09/cfl_if_badi_0101~get_datasource_mail.
        try.
            data(lo_msg) = get_io_message( is_data-instid ).
            if lo_msg is not bound.
              return.
            endif.

            " for usage in SO10 text variables, e.g. &/C09/CIO_IDX_ADMIN_EXTERNAL-NAME&
            /c09/cfl_cl_helper_0101=>add_datasource_mail( exporting is_datastruc         = lo_msg->mr_admin->_external
                                                          changing  ct_application_input = ct_application_input ).

            data(lo_tools) = /ubc/cl_tools=>get_instance( ).

            " set messages, link with SO10 main text
            data(lt_message) = lo_tools->convert_messages_bal_2_bapiret( lo_msg->get_bal_messages( ) ).
            insert value #(
                tdname = 'LOG_MESSAGES'
                tlines = lo_tools->convert_text_to_tlines_flat( lo_tools->build_html_table_for_bapiret2( lt_message ) ) )
                  into table ct_so10_text ##NO_TEXT.

            " add webgui link, link with SO10 main text
            data(lv_link) = lo_tools->get_gui_transaction_link(
                iv_transaction = /ubc/if_constants=>mc_cio-transaction_single-tcode
                it_parameter   = value #(
                    ( name = /ubc/if_constants=>mc_cio-transaction_single-parameters-message_id value = lo_msg->mr_key->msgguid )
                    ( name = /ubc/if_constants=>mc_cio-transaction_single-parameters-interface_name value = lo_msg->mr_admin->name ) ) ).
            insert value #( tdname = 'WEBGUI_LINK'
                            tlines = lo_tools->convert_text_to_tlines_flat( lv_link ) )
                  into table ct_so10_text ##NO_TEXT.
          catch /ubc/cx_core.
        endtry.
      endmethod.

      method /c09/cfl_if_badi_0101~get_description.
        data(lo_message) = get_io_message( is_data-instid ).
        if lo_message is not bound.
          return.
        endif.
        replace first occurrence of '&MSG&' in cv_description with |{ lo_message->mr_admin->msgnumber alpha = out }|.
        replace first occurrence of '&IF&' in cv_description with lo_message->mr_admin->name.
      endmethod.

      method /c09/cfl_if_badi_0101~get_object_info.
        cv_return = 'I/O message'(001).
      endmethod.

      method get_io_attributes.
        /c09/cl_cio_cfl=>get_instance( )->get_attributes_for_instid( exporting iv_instid = iv_instid
                                                                    importing ev_msg_id = ev_msg_id
                                                                              ev_ifname = ev_ifname ).
      endmethod.

      method get_io_message.
        get_io_attributes( exporting iv_instid = iv_instid
                          importing ev_msg_id = data(lv_msg_id)
                                    ev_ifname = data(lv_ifname) ).
        check lv_msg_id is not initial.
        ro_result = /c09/cl_cio_msg=>get_instance( iv_msgguid = lv_msg_id
                                                  iv_ifname  = lv_ifname ).
      endmethod.
    endclass.

Implementation​

warning

Please make sure to apply the following:

  • have your implementation without technical errors "no shortdumps"
  • return meaningful errors from your interfaces ("ET_RETURN") and avoid statements like "MESSAGE TYPE 'E'"

Otherwise, it will break the persistence rules and result in inconsistencies like

  • missing Run
  • Status "Pending" instead of Status "Error" Which are not critical from a transactional point of view, but from a error handling perspective it is not what a User would expect.

Triggering Interfaces (Top Level Function Module only)​

  • the Customizing was done for your top level function module
    If Multiple Steps are used, you are free to define the relation by customizing.
  • your top level function module has to be called just like any other function module in your coding. Make sure to have at least a COMMIT WORK at the end of your program in order to trigger the interface persistence.
  • make sure to include /UBC/IO_MACROS in your function group/module.
  • First statement in function module has to be _ubc_io_begin ''.
    warning

    the function module exits immediately, if not called by the framework and is asynchronous. The Exporting Parameters remains empty!

  • Last statement in function module has to be _ubc_io_end ''. The logging will be completed automatically by the framework.
  • make sure to have no explicit commits within your function module, as this will be controlled by the framework: Automatic commit if it was successfully and rollback if not. At least make sure to not have COMMIT WORK destroying auto restartability. If it is technically needed (for e.g. posting multiple Goods-Movements, consider using Multi Step Approach)
tip

The rest of your function module can remain untouched!

Multi Step Interfaces​

  • The Top Level Function Module, given in Assign technical interfaces to UBC.io interface has to match the previously described contract, see Triggering Interfaces.
  • Every "Step Function Module" must not include any macro again. It is controlled by the top level function module (begin and end) and just contains business logic!
  • The Top Level Function Module can (optionally) have initialization routines between the macros "begin" and "end"
  • Make sure that your Step Function Module also does not contain any COMMIT WORK or ROLLBACK WORK. This would destroy auto-restartability!
  • Your Step Function Module has to have absolutely the same function module signature as your top level function module. If you need to exchange information between steps, consider using a optional changing parameter (add to all your involved function modules) The parameters will be handed over to the next function

Templates​

To speed up development there are ABAP templates for the use of single functions and the use of functions with multiple steps/LUWs. Please have a look at the package /UBC/IO_TEMPLATE.

Business Add-Ins (BADIs)​

There is one enhancement spot called /C09/ES_CIO, containing:

Interface determination with /C09/BADI_CIO_FUNC​

Basically an assignment of Top Level Function Module to an Interface has to be unique. If this is not possible (used in multiple scenarios), this BADI has to be implemented. The target interface will be determined by the message payload in method /C09/IF_BADI_CIO_FUNC->DETERMINE_INTERFACE( ).

Add dynamic selection fields with /C09/BADI_CIO_DATA​

The BADI implementation can add specific logic to an Interface by implementing the interface /C09/IF_BADI_CIO_DATA.

System setup​

Technical setup is part of UBC system setup, so please execute the setup task list first with transaction /UBC/SETUP_BASIC.

bgRFC configuration​

In order to setup bgRFC processing, follow these steps:

The next steps depends on wether you want to use multiple bgRFC destinations for your interfaces or just use "one destination" for all of your UBC.io interfaces. Here you will find the steps needed to create a bgRFC destination + scheduler.

  • Create inbound destination The convention is that your name starts in your namespace (Z/Y). Here is an example of how to create the destination ZUBCIO_INBOUND:
    Inbound destination
    A few notes:
    • The server group (see transaction RZ12) should be not initial. Consider using at least standard parallel_generators. By not specifying a server group the bgRFC uses all qualified servers in an SAP System according to automatic resource-allocation rules. However, by defining server groups, you can control which servers can be used for paralle -processing. An RFC group specifies the set of allowed servers as well as a mechanism to not overload, e.g. "use only 75% of max. allowed dialog processes".
    • Prefixes A new prefix is needed for every queue in your UBC.io customizing. Without queue prefix no queued processing! So for example, your queue starts with the literals MATERIAL_, then you have to enter this prefix so that bgRFC queueing works correctly.
  • Create inbound scheduler
    Best practice: create the scheduler settings for your newly created destination.
    Inbound destination scheduler
    You can play around mit the maximum possible parallelization by changing "Open Connections".

Auto restart Job​

If you decide to configure Auto Restart, a Job needs to be scheduled to trigger Auto Restart after configured deadlines. In order to do so, schedule a Job for Report /C09/CIO_AUTORESTART in a period of 1 Minute. The auto restart of a single message does not get triggered as long as the minimum wait time was not reached.

Authorization​

The authorization object /UBC/IO_IF is used for restricting the usage of UBC.io interface monitors (Main Monitor /UBC/IO and Queue Monitor /UBC/IO_QUEUE). As UBC.io is organized by interfaces, the authorization object is also designed for restricting activites of specific interfaces. The following authorization fields are provided:

  • /UBC/IO_NM: interface name to restrict for, as chosen in UBC.io customizing (see /UBC/IO_C)
  • ACTVT: allowed activity/activites Possible values are:
    • 03 (Display)
      Restricts the display of messages. If no display activity is maintained for a specific interface, the message will not be shown in the I/O monitors.
    • 91 (Reactivate)
      Restricts the availability of operation Restart in I/O monitors.
    • 04 (Print, edit messages)
      Restricts the availability of operation Edit in I/O monitors.
    • 90 (Copy)
      Restricts the availability of operation Copy in I/O monitors.
    • 31 (Confirm)
      Restricts the availability of operation Acknowledge in I/O monitors.
    • 02 (Change)
      This activity acts as a collective one which includes all the changing operations from above:
      • Restart
      • Edit
      • Copy
      • Acknowledge
        tip

        We recommend to use the dedicated activites mentioned above.

Data Archiving​

UBC.io comes with a dedicated Archiving Object /C09/CIO, used to archive all the data which was persisted to monitor and process the messages. As in most SAP standard applications the archive runs are scheduled within transaction SARA. The write step offers multiple options to select the messages. Please note that only messages will be archived which are in a completed state. Only own persistency:

  • index table entries
  • workflows in a completed step started by workflow integration, see Workflow Integration

will be archived.

info

the write step does not trigger data archiving of a connected business object or IDOC. If needed, data archiving can also be included in customer archiving routines, calling methods of /C09/IF_CIO_ARC_MSG_SERVICE.