Wildcard ICO migration

PI Integrated Configurations (ICOs) whose sender or receiver is a wildcard (*) are migrated since 2609.1. Such an ICO holds only the shared part of an integration, while the channel of every real sender or receiver system is defined in a Sender Agreement or a Receiver Agreement. This page describes where the migration takes the channels from and how the result differs per migration profile.

The agreements are found through the links created during synchronization of the PI agent. If an agreement is missing on the Migration page, check it in PI and synchronize the PI agent.

1. Wildcard sender

An ICO whose sender party or component is * has no sender channel of its own: the sender channel of every real sender system is defined in a Sender Agreement for the same interface. Such ICOs are listed on the Overview page next to normal ICOs and are migrated from the Overview or the Migration page in the same way.

1.1. Sender Agreement selection

In the Single Process, Local Processes, Pipeline Inbound Processing and Pipeline Inbound Conversion profiles the migrated IFlow has one sender adapter, so one Sender Agreement provides it. After Check the Migration page shows the Sender Agreement field with every linked Sender Agreement and its sender channel:

  • The first agreement (by name) is preselected and its channel is migrated. With several linked agreements the migration logs carry a warning that names the preselected one.

  • To migrate the channel of another agreement, select it and run Check again. The choice is stored with the migration settings of the ICO and restored on the next check.

  • The agreement’s sender party and component replace the * in the sender participant name, the channel mapping and the template parameters of the generated IFlow. In the Pipeline Inbound Conversion profile the sender participant is named Wildcard instead, because the conversion IFlow serves every sender of the ICO.

  • If the stored agreement isn’t linked anymore (deleted, or re-linked by synchronization), the check warns about it and falls back to the first linked agreement.

1.2. Pipeline All profile

No agreement is selected. One Inbound Processing IFlow is created per linked Sender Agreement, with that agreement’s sender channel and named after its sender (plus the receiver of the agreement key when two agreements have the same sender). The Inbound IFlows table lists them with their Sender; each can be excluded, renamed and previewed as usual, and a repeated check keeps these settings for the agreements that are still linked.

  • The Inbound Conversion IFlow is created once, from the sender channel of the first linked agreement. With several agreements the migration logs carry an information entry that names the agreement used.

  • The Outbound IFlows are created once and take nothing from the agreements. Their sender participant is named Wildcard, and the Sender field of the migration settings defaults to Wildcard.

  • After the migration every Inbound Processing IFlow gets its own IFlow chain with the shared conversion and outbound IFlows, so test cases can be run per sender. A Partner Directory alternative partner is created for the sender of every included Inbound IFlow.

  • The check reports an error when two IFlows or two chains would get the same technical name, and Migrate refuses such a request, because CPI would overwrite one IFlow with the other.

1.3. Pipeline Outbound profile

The Outbound IFlow receives its messages from the pipeline, so no Sender Agreement is applied: the Sender Agreement field isn’t shown, the sender participant is named Wildcard and the migration logs carry an information entry that says so.

1.4. Warning about differently converting channels

The shared Inbound Conversion IFlow is built from one sender channel but serves every sender of the ICO. During Check of a Pipeline All or Pipeline Inbound Conversion migration the sender channels of all linked agreements are compared: adapter, message protocol, File Content Conversion settings, custom modules and their parameters (connection details and logging modules are ignored). When a channel differs from the one the conversion was built from, the migration logs carry a warning that names the agreement used, each differing agreement and the differing part, for example 'PartnerB|CompB' (message protocol). The generated IFlows don’t change: adjust the conversion for such senders manually after the migration.

1.5. No linked Sender Agreement

The check completes, but the generated IFlow has no sender adapter and its sender participant is named Wildcard. The migration logs carry the manual action Channel is not found for Sender | and a warning that advises to check the Sender Agreements in PI and to synchronize the PI agent.

1.6. Test cases

The test cases of a wildcard sender scenario belong to the Sender Agreement, not to the ICO, so they aren’t offered by Migrate Test cases on the Overview page. Open the Agent Test Cases tab of the Sender Agreement, click Migrate to CPI and select the migrated IFlow or IFlow chain manually (see Migrate test cases from PI to CPI).

2. Wildcard receiver

An ICO whose Receiver Interfaces are defined for the wildcard receiver | carries the sender channel, the receiver determination and the interface determination, but no receiver channels: the channel of every real receiver is defined in a Receiver Agreement keyed by the ICO’s sender, the receiver interface and the receiver. There is no new field on the Migration page: the only difference to a normal ICO is where the receivers and their channels come from.

  • For an ICO with static receiver rules the receivers are those of the rules, plus the default receiver of the Receiver tab. A linked Receiver Agreement whose receiver is named by no rule isn’t used, and the migration logs carry an information entry about it.

  • For an ICO with Extended Receiver Determination or external receiver rules the receivers are those of the linked Receiver Agreements, because the ICO itself names none.

  • Every Receiver Interfaces block defined for the wildcard receiver applies to each receiver with the same interfaces, operations, mappings and conditions. The channel of every receiver and interface is taken from the Receiver Agreement with that receiver and interface and is listed in the Channels Mapping table as usual. The migration logs carry an information entry naming the agreements used.

  • A receiver and interface without a matching Receiver Agreement is migrated without a receiver adapter. The migration logs carry the manual action Channel is not found for Receiver …​ and a warning that advises to check the Receiver Agreements in PI and to synchronize the PI agent. With Extended Receiver Determination and no linked agreement at all, the Receivers/Interfaces table stays empty and one warning explains it.

The generated IFlow is the same as for a normal ICO with these receivers: one router branch per receiver, each ending in the receiver adapter of that receiver’s agreement. Pipeline All creates one Outbound IFlow per receiver and interface, as usual. Test cases of such an ICO belong to the ICO and are migrated as for a normal ICO.

3. Limitations

  • An ICO with a wildcard on both sides (sender and receiver ) isn’t supported: synchronization links its Sender Agreements only.

  • A Receiver Agreement with a sender or a interface isn’t linked to the ICO by synchronization, so the migration doesn’t see it. Its receiver is then missing (Extended Receiver Determination) or reported as a missing channel (static rules).