Round-trip write-back for grouped Safran schedules using enterprise fields

What this lets you do

A round-trip sends your Safran data out to another system, lets it be updated there, and then writes the changes back into your own Safran projects — automatically, into the exact project each activity came from.

This builds on a virtual schedule — the grouped schedule that bundles several Safran projects into one, described in Writing out of Safran. On the way out, that group is sent as one package. On the return leg, this feature takes the data that comes back and routes each activity into the exact source project it originally came from.

Warning: A round-trip writes to your live Safran projects. Unlike a one-way transfer to a partner, it changes your own schedules. Read Conflicts, removals and safety before you activate one, and keep Only Include Specified Mappings on unless you specifically want core fields overwritten.

Contents

1. What this applies to
2. Before you start
3. The grouped schedule you write back to
4. Set up the write-back agreement
5. Only Include Specified Mappings
6. How write-back behaves
7. What is and is not written back
8. Conflicts, removals and safety
9. Constraints and limitations
10. Messages in the transfer log
11. Avoiding common errors
12. Related guides

What this applies to

Before you start

A write-back agreement can only be saved when all of these are true. If one is missing, SchedEx blocks the save and the message tells you which rule failed.

The first-leg source and the write-back target must be the same schedule on the same connector.

Note: Beyond these save rules, running the write-back needs an up-to-date client. Writing into a virtual schedule (the per-network import) requires desktop client / Autonomous Client 2.17.0.0 or later — sending the group out needs only 2.15.0.0. An older receiving client is refused with "Downloading into a virtual schedule requires client version 2.17.0.0 or later."

The grouped schedule you write back to

The write-back target is the same virtual schedule you send out — created and managed on the Safran connector's Persisted Data → Schedules tab. You can recognise it by its blue Virtual chip and a Schedule ID that starts with Virtual_ (for example Virtual_21081); it has no start or finish date of its own. The same chip appears on the Config's Schedule tab and on the agreement's Schedule identifier, so you can confirm the receiving side really is the grouped schedule.

Open its View Details to confirm the group: the base host fields, the grouping filter, and the projects it currently matches.

SchedEx uses this same grouping rule on the return leg to decide which project each returning activity belongs to. If you need to create or adjust the group first, see Writing out of Safran.

Set up the write-back agreement

Configure these on the follow-up (write-back) Exchange Agreement — the one that runs after the send-out agreement:

1. Receiving target = the grouped schedule. On the receiving side, select the Safran virtual grouped schedule. (Previously a grouped schedule could only be chosen for sending; it can now be a receiving target too.)
2. Frequency = Predecessor. Set the agreement's frequency to Predecessor, then select the send-out agreement as the predecessor. This chains the write-back to run straight after the data goes out and comes back.
3. Keep Only Include Specified Mappings on. It is on by default for a round-trip. See Only Include Specified Mappings before turning it off.
4. Set your conflict option. Choose how the agreement resolves conflicts before activating — it applies to every project in the group (see Conflicts, removals and safety).

Tip: If Save is blocked, the message names the rule that failed — most often the receiving connector is not the same Safran connector the predecessor sends from, or the frequency is not set to Predecessor.

Only Include Specified Mappings

This setting controls how much of each activity the write-back is allowed to change in your live Safran projects. SchedEx turns it on automatically for a Safran virtual receiver with a predecessor — you can accept that default (recommended) or turn it off.

Codes. With the setting on, an activity's code changes only if you mapped the code. With it off, code changes flow back to the source. Whenever a code is written back, the grouping prefix added on the way out — for example 500_112 — is stripped back to the real source code, 112.

Warning: Turning this off lets the write-back overwrite core fields in your live Safran projects. The confirmation prompt appears immediately when you switch it off, not at save. Leave it on unless you specifically intend to push core fields back. This enforcement applies while the frequency is Predecessor; changing the frequency removes it.

How write-back behaves

On each run, SchedEx:

• Reads the current Safran projects live and matches them against the group's filter.
• Routes each returning activity back to its originating project, matched through SchedEx's reference data rather than by code.
• Restores the original code by removing the grouping prefix.
• Skips any project that no longer matches the filter (or no longer exists), and notes it in the transfer log.
• Resolves conflicts per project, using the single agreement-level conflict option.

Because the match is on reference data, an activity returns to the correct project even if two projects happen to share the same code.

What is and is not written back

Not written back:

• New objects created at the intermediary. New activities — and new resources, calendars, structures or profiles created on the first-leg destination — have no source origin, so they are not created in Safran.
• Cross-project links. A dependency created between activities from two different source projects cannot live in a single project, so it is skipped with a warning.
• Re-classified or deleted projects. A project whose grouping value changed, or that was deleted in Safran, drops out of the group and is skipped.
• Project-group grouping — only enterprise-field grouping is supported.

How each code set, calendar, resource and profile is handled

On the way out, same-named code sets, calendars, resources and profiles from the grouped projects are combined into one package (see Different code sets, calendars, resources and profiles in the send-out guide). On the way back, SchedEx updates the matching existing item in each project and leaves brand-new shared objects out — a new shared object has no source project to return to:

So a round-trip keeps your shared libraries — calendars, resources, profiles and code sets — in step by updating them, but it never introduces a brand-new shared object into Safran from the intermediary. If you need a new calendar or resource in the source, add it in Safran directly.

Note: A group may contain projects that use different code sets. On write-back, each project's own structures are updated within that project, so mixed code sets are handled correctly per project. (On the send-out side, the base-schedule choice used when creating the virtual schedule has little impact and is planned to be removed in an upcoming release — see the send-out guide.)

Conflicts, removals and safety

Write-back follows SchedEx's normal Safran download rules, applied per project:

• Before anything is written, SchedEx checks every member project. If a shared object (a calendar, resource, profile or structure) points to different Safran objects in different projects, the write-back cannot tell which to update, so the whole transfer stops with "These shared objects point to different Safran objects in the projects of the virtual schedule, so the transfer cannot tell which one to update: … No data was transferred." Make that shared object the same across the projects (or narrow the group), then run again. This is an all-or-nothing, pre-write check — separate from the per-project conflict handling below.
• Objects with independent changes in the source are resolved using the single agreement-level conflict option, applied uniformly to every project in the group.
• Removals follow normal download behaviour.
• An unresolved conflict stops that project's write-back only — the other projects in the group still complete.

Warning: A round-trip writes to your live source. Unlike a one-way transfer to a partner, it changes your own Safran projects. Keep Only Include Specified Mappings on unless you specifically want core fields overwritten, and confirm your conflict option before activating.

Constraints and limitations

Messages in the transfer log

Always check the transfer log after a write-back run. Common messages:

Avoiding common errors

Related guides

• Writing out of Safran: group several schedules into one exchange — create and manage the virtual grouped schedule, and send it out.
• Glossary — shared SchedEx terms (Tenant, IEA, Config, Data Transfer).