IBM C1000-150 common mistakes
IBM C1000-150 · Understand the traps and how to avoid them.
Treating webMethods Integration Server package dependencies as automatically resolved at runtime, so a package with a missing or circular dependency is deployed and then fails when a service is invoked.
Candidates often focus only on the service flow logic and assume the server will handle package wiring, but Integration Server resolves dependencies at package activation and circular references block activation.
What to do instead
Before deploying, inspect each package's manifest for declared dependencies, build a dependency graph, and eliminate cycles by refactoring shared utilities into a base package. Test activation in a staging environment and verify that all referenced packages are enabled.
Configuring the webMethods Universal Messaging or Broker connection with the wrong channel or queue permissions and then blaming the service code when messages are not delivered.
Messaging configuration is often copied from examples without checking the destination's ACLs, and candidates rarely test with the actual service account used at runtime.
What to do instead
Verify the connection's user has publish/subscribe rights on the exact channel or queue, confirm the destination name and type (queue vs. topic) match the service's expectations, and test with a small standalone publisher/subscriber before integrating.
Writing flow services that catch all exceptions with a single broad try/catch and then continue, so partial writes and inconsistent state go undetected.
Candidates want to make the flow 'not fail' and treat error handling as a formality, not realizing that swallowing exceptions hides transaction boundaries and data integrity problems.
What to do instead
Catch specific exception types, log the full error with context, mark the transaction for rollback where supported, and rethrow or route to a dead-letter flow. Add explicit failure-path tests that assert the rollback or compensation behavior.
Assuming a JDBC adapter service automatically commits or rolls back based on the flow's success, when transaction management is actually controlled by the adapter's transaction type setting.
The adapter's transaction type (NO_TRANSACTION, LOCAL_TRANSACTION, XA_TRANSACTION) determines commit behavior, but candidates often leave the default and expect container-managed semantics.
What to do instead
Explicitly set the adapter transaction type to match the required atomicity, ensure XA is used only when multiple resources must be coordinated, and test rollback by forcing a downstream failure and verifying no partial rows remain.
Deploying the same webMethods package to multiple Integration Server instances without externalizing environment-specific properties, causing hard-coded hostnames or credentials to break in another environment.
Candidates test only in the development environment and treat configuration as code, overlooking the need for environment-specific property files or global variables.
What to do instead
Move all environment-specific values into Integration Server global variables, extended settings, or external property files, use the same package binary across environments, and validate by deploying to a second environment with different values.
Using the webMethods Mediator or API Gateway policy editor to add a policy but forgetting to attach it to the API or to set the policy's enforcement mode to active.
The policy creation step feels complete, and the UI may show the policy in the list without indicating it is unattached or in monitor-only mode.
What to do instead
After creating a policy, explicitly attach it to the target API or service, set enforcement to active (not monitor), and test with a request that should be blocked to confirm the policy is applied.
Misreading the webMethods Integration Server log levels and setting the root logger to DEBUG in production to troubleshoot, then leaving it there.
Candidates use DEBUG to get more detail during an incident but do not revert it, causing performance degradation and log volume issues.
What to do instead
Use targeted loggers for the specific package or service, set the root logger back to INFO or WARN after troubleshooting, and configure log rotation and retention to prevent disk exhaustion.
Assuming webMethods Deployer will automatically include dependent packages or configurations when building a deployment set, leading to missing artifacts at the target.
Deployer builds a set from selected assets, but dependencies are not always pulled in automatically, and candidates skip the dependency check step.
What to do instead
Use the Deployer dependency analysis feature to include all required packages, verify the deployment set manifest lists every artifact, and perform a dry run or staged deployment to confirm completeness before promoting.
Configuring a webMethods Trading Networks partner profile with the wrong document type or processing rule and then expecting the document to be recognized, when the recognition depends on the exact envelope and document type mapping.
Candidates focus on the partner ID and ignore that Trading Networks matches documents by document type, sender/receiver, and processing rule, so a mismatched type silently fails recognition.
What to do instead
Verify the document type definition matches the actual payload structure, confirm the processing rule's criteria (sender, receiver, document type) align with the partner profile, and test with a sample document while checking the Trading Networks activity log for recognition results.
Writing unit tests for flow services that only cover the happy path and mock all outbound calls, so integration issues with adapters and messaging are never exercised.
Candidates treat unit tests as a checkbox and avoid the complexity of setting up test adapters or messaging, leaving integration behavior unverified.
What to do instead
Add integration tests that run against a test Integration Server with real or containerized adapter endpoints and messaging, and include negative tests for timeouts, connection failures, and malformed responses. Use the webMethods test suite or a harness that can invoke services end-to-end.