Hi,

Until today, to deploy some web services or parts/elements of web services (ex : documents, service flow), I used to create One Project, each time for One build (For each projects, I have a one only build).

But, looking the Deployer structure, I’ve realized, I could make many Builds for the same project.

So, to deploy a new element (ex : a document has changes) I’ve tried this new way to in using an existing project :

• I’ve created a new (second) Set
  (Warning one first Line : Project definition has changed since the Build : → that seems normal)
• I’ve created a new (second) Build line version
• I’ve created a new (second) Deployment Map line and associated the Target IS
• I’ve created a new (second) Deployment Candidat

But after the last step I’m obtaining a new warning :
“The Deployment Map associated with this Deployment Candidate contains partially mapped Target Server(s)/Group(s)”

So I’ve many questions :

• Why this last warning ? I verified : the Set#2 is well associated
• Is it really a good pratice to create new builds inside a same project ?

Regards

#webMethods-General
#Integration-Server-and-ESB
#webMethods

Whch Verion aret you seeing this in?

Im assuming that in the second map you left the map for the 1st set blank and webMethods is reminding you that you may have missed a set.
but as long as you are sure that you do not want to map the original set you should be good

The way i do it is whenevere i have multiple sets ,the second set us usually contains elements exclusive to those in the first set ,but part of the same logical project.(Eg Process model in one set abd the implementation code in the other)
That way I keep the sets clean and easier to handle dependency checking and less number of mapping lines required.

Each time i would deploy the whole shebang to ensure build sanity.(You can always roll-back if you dont like it)

There was at lease one use case where we had to use a different set/Project while deploying TN components to a Cluster.as the backend database in a cluster is the same.This was with 9.8 i think.Not sure how the behaviour is for higher versions.

#webMethods
#Integration-Server-and-ESB
#webMethods-General

Hi,

Thanks for your reply. I’m on 9.8.

Ok, if it is just a warning that reminding me I have maybe missed a set, it 's ok for me.

Thanks for the idea of creating set with exclusive data…
Maybe I have to try this way too

Regards

#Integration-Server-and-ESB
#webMethods
#webMethods-General

Hi,

Hum…I’m meeting another problem :

I’ve moved a service from a directory to another directory.
Then I want to redeploy my service.

So, I’ve kept my existing Deployer project,
I’ve created a new (third) Set
I’ve created a new (third) Build
but when Deployer tried to compile, it throwed me an error :
[DEP.0001.0041] Deployment set IS has unresolved dependencies and could result in an incomplete deployment. Use the Deployer user interface to resolve the dependencies

And after, the previous build are placed in warning mode (yellow icon)
And I can’t do anything to make my build compilable

The only (bad) way I found, to repair it, was :

• to modify the 2 previous Sets, and re unloading/loadind service (because of the missing moved file),
• to rebuild tje 2 previous Builds

anf then the last Build can compile (green check).

I’m not satisfied with that because I did not want to modify my previous Builds.

In this case, what is the problem please ?

Is it a Deployer bug… or is normal ?
in this case, am I obliged to create a new project (for a such a litle modification) ?

Regards

#Integration-Server-and-ESB
#webMethods
#webMethods-General

Hi Cedric,

when creating additional sets it is expected behaviour that previous build become yellow.
They are marked as “Project definition changed since time of build”.

As the third Set will only contain the new service you should go “Check dependencies” and find out which other objects (services, documents, …) it is referring to. Usually these can be marked as “Exists” as they have been deployed earlier.

As you said you have moved the service you will need to delete the old service.
To do so go the properties of the package and fill the files to delete section.
For a flow service specify the files in following order:

• ns/path to service/node.ndf
• ns/path to service/flow.xml
• ns/path to service/flow.xml.bak
• ns/path to service itself

The other option to delete services is to create a deletion set in deployer and specify the service. But this requires the old service to be still present on source environment.

See Deployer Users Guide for further informations.

Regards,
Holger

#Integration-Server-and-ESB
#webMethods-General
#webMethods

Hi Holger,

Yes I understand that the previous builds become yellow as “Project definition changed since time of build”.

But it my case, creating a new Build throwed an error (red icone) because of unresolved dependencies.
[DEP.0001.0041] Deployment set IS has unresolved dependencies and could result in an incomplete deployment. Use the Deployer user interface to resolve the dependencies

but for the concerned Set (the last one) I’ve verifyed that all the dependencies were resolved (the chek was green after selected ‘Exists’).
and despite of the green checking set, the last Build stayed red (even after rebuilding).

So, I suspect my new Build was in error because of the others previous sets ( yellow) and builds (because of the file moved).

Maybe a bug ?

Regards

#Integration-Server-and-ESB
#webMethods
#webMethods-General

Hi Cedric,

this is expected behaviour, as the previous sets still have references to the old service.

You will have to re-resolve the dependencies for this service.

There should be no need to rebuild the previous builds.

We are currently following a different approach:
When the changes to our applications exceed a certain amount of nodes affected or if we have to migrate from one platform to another, we produce a set of Builds with new major version (project names contain the version number) and Builds are named Initial_Build to indicate that this build serves as a base line for upcoming builds of the same application part. Together with these intial builds we also deliver the neccessary configuration and properties files.
For minor changes we produce additional projects where the sets only contain the latest changes for particular implementation tasks and then the build will be named Partial to indicate that it only contains neccessary nodes and should be deloyed in order of the minor versions (if there several of them for one specific application part) on top of the last major version.
Each of these projects only contain build and will never be touched again.

This increases the number of projects to be created in Deployer but reduces irritations like “Project definition changed” or builds failing due to outdated dependency resolutions.

Regards,
Holger

#webMethods-General
#webMethods
#Integration-Server-and-ESB

Hi,

I really hope, I do not need to Rebuild the previous Builds. I will try again, you’re probably right, so I would just need to resolve previsous sets.

I unfortunately did not find any useful informations in the official “9-8_Deployer_Users_Guide” about the way to do with major, minor version, and multi bulids.
So I’m creating a way to do, getting first, from all your advices and differents forum links and web articles.

For examples, the only doc I’ve found about Deployer’s naming conventions are these ones :

I think, there is a real lack in the official Deployment webMethods guides…

So here is what I do :

Project :

0001_WS_PART_26012017

IS_Set1 (new service A)
→ Build : V1.1.16
→ MAP : Preproduction-dep1
→ Deployment : V1.1.16_Preproduction-dep1

IS_Set2 (service A, modification)
→ Build : V1.1.17
→ MAP : Preproduction-dep2
→ Deployment : V1.1.17_Preproduction-dep2

IS_Set3 (service A, adding service java)
→ Build : V1.1.18
→ MAP : Preproduction-dep3
→ Deployment : V1.1.18_Preproduction-dep3

is it a good pratice ?

Regards

#webMethods
#webMethods-General
#Integration-Server-and-ESB

It sounds like you're exploring a more flexible approach to manage deployments within the same project, which is a valid idea in many cases. Let's address your questions:

1. Why the last warning?

The warning, "The Deployment Map associated with this Deployment Candidate contains partially mapped Target Server(s)/Group(s)," indicates that not all elements in your Deployment Map are fully associated with a target server or group. This often happens when:

• A new Set or Build contains elements that aren't correctly linked to a target.
• The Target IS (Integration Server) or server group you associated with your Deployment Map doesn't cover all components in the new Set.

How to resolve:

• Double-check your Deployment Map configuration for Set#2.
• Ensure every element in your Set#2 is mapped to the appropriate target server(s).
• If some components don't need deployment, explicitly mark them as excluded.

2. Is it good practice to create multiple builds in the same project?

Yes, creating multiple builds in the same project can be a good practice if used correctly, as it can:

• Save time: Avoid creating new projects for minor changes or updates.
• Simplify management: Maintain related builds in a single, cohesive structure.
• Support incremental updates: Deploy only the changes without re-deploying the entire project.

However, it depends on the complexity of your project:

• When to use multiple builds: If your changes are relatively small and incremental (like updating a document or a minor configuration).
• When to avoid: If your deployments frequently affect unrelated elements or the project becomes too cluttered. In such cases, separating projects might reduce confusion.

Recommendations:

• For Set#2, resolve the warning by fully mapping the Deployment Map to the target(s).
• Use multiple builds sparingly and document the changes and purposes of each build within the project. This helps avoid confusion among team members or during troubleshooting.

If you continue encountering issues, sharing specifics about the Deployment Map or Target Server configuration could help identify the root cause!

------------------------------
Roman Ali
------------------------------

Original Message:
Sent: Mon January 30, 2017 03:49 PM
From: webMethods Community Member
Subject: Deployer : how to deal with multiple Builds within a same project

Hi,

Until today, to deploy some web services or parts/elements of web services (ex : documents, service flow), I used to create One Project, each time for One build (For each projects, I have a one only build).

But, looking the Deployer structure, I've realized, I could make many Builds for the same project.

So, to deploy a new element (ex : a document has changes) I've tried this new way to in using an existing project :

• I've created a new (second) Set
  (Warning one first Line : Project definition has changed since the Build : → that seems normal)
• I've created a new (second) Build line version
• I've created a new (second) Deployment Map line and associated the Target IS
• I've created a new (second) Deployment Candidat

But after the last step I'm obtaining a new warning :
"The Deployment Map associated with this Deployment Candidate contains partially mapped Target Server(s)/Group(s)"

So I've many questions :

• Why this last warning ? I verified : the Set#2 is well associated
• Is it really a good pratice to create new builds inside a same project ?

Regards

#webMethods-General
#Integration-Server-and-ESB
#webMethods

Hi Cedric and all,

Thanks for the thorough discussion - I'd like to summarize and add clarity based on experience managing multi-build projects in webMethods Deployer (we're also on 9.8 and newer versions).

Is it a good practice to use multiple Builds in the same Project?

Yes, using multiple Builds within the same Deployer project is a valid and recommended practice if used with care:

• It keeps related deployments logically grouped.

• You can easily trace evolution (V1.1.16 → V1.1.17 → etc.).

• It avoids duplication of project-level configuration.

That said, it introduces complexity:

• All builds are affected if the project structure (Sets, assets) changes.

• Old builds turn yellow (⚠️) if sets change - expected behavior.

• Dependencies and file moves can break newer builds if older ones are unresolved.

---

About the Warning: "Deployment Map... partially mapped…"

This means your Deployment Map has some components (possibly from other Sets) that are:

• Not fully mapped to a Target server.

• Unselected or left as-is in earlier Sets (often unintentionally).

Fix:

1. Go to the Deployment Map.

2. For all Sets in the Build, ensure each element is either:

   • Mapped to a target IS.

   • Explicitly excluded (if not required).

---

Error on Rebuilding New Set After Moving Files

When you move or rename a service, dependencies in other sets (even if unchanged) become broken. That's why your new Set Build failed - even though it seemed self-contained.

Solution:

• As Holger mentioned, use the dependency checker and mark existing dependencies as "Exists" (after confirming).

• For moved services, always clean up old paths:

  • Either delete them via a deletion Set.

  • Or specify them in the "files to delete" section of the Package.

Tip: If source has already removed them, deletion Set won't work - use the property-based delete.

---

📁 Suggested Naming Convention & Practice

You're on the right track. A clear, versioned approach helps, especially when maintained consistently.

For example:

sql


CopyEdit


Project: 0001_WS_PART_26012017

Set 1: Initial version of Service A → Build V1.1.16 → Deployment V1.1.16_PreProd
Set 2: Update of Service A → Build V1.1.17 → Deployment V1.1.17_PreProd
Set 3: Added Java Service B → Build V1.1.18 → Deployment V1.1.18_PreProd

Make sure:

• Each Set is self-contained or clearly dependent.

• Document which build depends on which previous ones.

• If major changes are made (e.g., moved assets), consider creating a new Deployer Project (e.g., 0001_WS_PART_v2_YYYYMMDD) to avoid risking regression on previous builds.

---

Best Practice Summary

•  Multiple Builds in the same Project → Good for incremental deployments.

•  Watch out for broken dependencies when services are moved or deleted.

•  Resolve all dependencies for each Set before building.

•  Use "Exists" status wisely in dependency resolution.

•  Clean up old services using deletion Sets or explicit file deletion.

Let me know if you need help debugging a specific Build/Set/Map structure - happy to help further.

Best regards,

------------------------------
MYKHAILO BIELICHENKO
------------------------------

Original Message:
Sent: Mon January 30, 2017 03:49 PM
From: webMethods Community Member
Subject: Deployer : how to deal with multiple Builds within a same project

Hi,

Until today, to deploy some web services or parts/elements of web services (ex : documents, service flow), I used to create One Project, each time for One build (For each projects, I have a one only build).

But, looking the Deployer structure, I've realized, I could make many Builds for the same project.

So, to deploy a new element (ex : a document has changes) I've tried this new way to in using an existing project :

• I've created a new (second) Set
  (Warning one first Line : Project definition has changed since the Build : → that seems normal)
• I've created a new (second) Build line version
• I've created a new (second) Deployment Map line and associated the Target IS
• I've created a new (second) Deployment Candidat

But after the last step I'm obtaining a new warning :
"The Deployment Map associated with this Deployment Candidate contains partially mapped Target Server(s)/Group(s)"

So I've many questions :

• Why this last warning ? I verified : the Set#2 is well associated
• Is it really a good pratice to create new builds inside a same project ?

Regards

#webMethods-General
#Integration-Server-and-ESB
#webMethods