• Success
    Manage your Success Plans and Engagements, gain key insights into your implementation journey, and collaborate with your CSMs
    Success
    Accelerate your Purchase to Value engaging with Informatica Architects for Customer Success
  • Communities
    A collaborative platform to connect and grow with like-minded Informaticans across the globe
    Communities
    Connect and collaborate with Informatica experts and champions
    Have a question? Start a Discussion and get immediate answers you are looking for
    Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
  • Knowledge Center
    Troubleshooting documents, product guides, how to videos, best practices, and more
    Knowledge Center
    One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
    Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
    Information library of the latest product documents
    Best practices and use cases from the Implementation team
  • Learn
    Rich resources to help you leverage full capabilities of our products
    Learn
    Role-based training programs for the best ROI
    Get certified on Informatica products. Free, Foundation, or Professional
    Free and unlimited modules based on your expertise level and journey
    Self-guided, intuitive experience platform for outcome-focused product capabilities and use cases
  • Resources
    Library of content to help you leverage the best of Informatica products
    Resources
    Most popular webinars on product architecture, best practices, and more
    Product Availability Matrix statements of Informatica products
    Monthly support newsletter
    Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
    End of Life statements of Informatica products
Last Updated Date May 25, 2021 |

Challenge

ActiveVOS resources such as bpel, wsdl and schema files are uniquely defined by targetnamespaces. Although it is a bad idea to have two objects with the same targetnamespace in a workspace or on a server, there are times when the same resources are used by different projects and need to be available to both. This is one reason why it is best to separate out common resources into common projects. This will also help to avoid redundancies and inconsistencies between two versions of the same resource.

Description

This best practice document explains why common resources should be separated from project resources.

Identifying a Common Resource

Some common resources are easy to identify (e.g., CommonHeader.xsd, CompanyHolidays.xml, etc.) while identifying others may not be as obvious. A simple rule to follow is, if a resource is used by more than one project it is generally a common resource. As with any rule there may be exceptions. If two projects are closely related and one references the other, and these are the only two projects that use the resource, then the resource should probably be in the parent of the two projects.

As with all best practice cases, the rule (and any exceptions to the rule) should be documented.

Example Rule:

Common Resources Rule.

All wsdls, schemas, and XQuery modules that are used by more than one project will be defined as common resources and will exist in a common project.

Exceptions.

Resources used only in the CustomerSurvey Project and the CustomerSurveyExtras Project will be defined as common CustomerSurvey resources and will be stored in the CustomerSurvey Project.

As illustrated above, be specific about exceptions.

Placement of Common Resources

Although as a best practice common resources should be in a common project, there is no real requirement as to what that/those project(s) should be called. Common Resources can be in many different common projects. The projects can be called Common, or CommonResources or any name (e.g., MyProject), but the project name should be indicative of what the project contains. For example:

  • CustomerResources
  • ABCInsurance
  • SurveyWsdls

Another case for using Common projects for resources that may be used only once, is for external resources. If external resources are provided (i.e., wsdls and schema pointing to external services) they should be separated from the application Project. In this way, when the external system makes changes they can be addressed in a project specifically for that system.

For example, if projects use a selection of WSDL and XML schema resources to interact with web services offered by Yahoo Shopping, and those resources have been obtained from Yahoo, then it is appropriate to dedicate a common resource project to hold those files, called “YahooShoppingResources” or something similar.

Splitting Common Resources

In a case where there are a lot of common resources, it is best not to put them all in one basket.

Determine which resources should be separated and group them to match the way they are used.

If a developer has to import a project that has too many resources (every time they work on any project) the overhead may become too much. It is better if the developer only has to import resources that are required in the common projects they are using.

To implement this, just group the resources into separate projects. The grouping should be determined by the use of the resources.

Document all decisions on Splitting resources as well.

Example:

  • Resources relating to company standards are in a project called Common
  • Customer Services Common resources are stored in CustomerServiceResources
  • Product Application resources are stored in ProjectResources
  • External Services resources are stored in ExternalServices
  • Other common resources are stored in CommonResources

Table of Contents

Success

Link Copied to Clipboard