IV37993: ABILITY TO CONFIGURE PRODUCTION CLASSIFICATION TO PROMOTE TO MULTIPLE RUNTIMES

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • In cases where customers have multiple runtime instances for
    Production runtime, they would like the ability to promote to
    all the runtimes in the promotion properties while hiding the
    complexity to the user.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    All users of WebSphere Service Registry and Repository Server
    Version 7.5.0 and WebSphere Service Registry and Repository
    Server Version 8.0.0
    
    ****************************************************************
    PROBLEM SUMMARY:
    Customer needs to have multiple promotions to geographically
    distinct systems at the same functional level (e.g.
    Staging/Production).
    

Problem conclusion

  • The promotion code has been modified to allow for immediate
    child classifications of the main environment classification to
    drive promotion.
    
    An example of this would be where there a single logical staging
    environment but it is composed of separate WSRR instances that
    are not clustered. For example, when there is a large geographic
    distance between servers, clustering is not appropriate because
    of the large latency that such distances would impose.
    
    So the logical Staging environment is split into three physical
    instances in different data centers. The three child
    environments would be actual subclasses of Staging.
    
    Staging
           -> StagingEast
           -> StagingWest
           -> StagingCentral
    
    And the PromotionProperties configuration item would define
    these environments in the normal way ...
    
    
    
    
    
    All three staging environments must be explictly listed for a
    transition that should trigger a promotion to the logical
    Staging environment...
    
    
      name="http://...
    LifecycleDefinition#ApproveStagingDeployment">
    
         http:/...GovernanceProfileTaxonomy#StagingEast
         http:/...GovernanceProfileTaxonomy#StagingWest
         http:/...GovernanceProfileTaxonomy#StagingCentral
    
    
    
    When an object undergoes the ApproveStagingDeployment
    transition, three promotions would be triggered. One to each of
    the three physical Staging environments. Objects would only ever
    be classified by the parent environment, in this case, Staging,
    because there is conceptually only a single staging environment.
    
    Prior to this APAR this technique would not have been possible
    because objects classified with only the "Staging"
    classification would have been filtered out when promoting to
    one of the actual staging instances, such as "StagingWest". This
    APAR prevents objects in WSRR from having to be classified with,
    in addition to their logical environment classification,
    classifications for each physical instances that comprise the
    logical environment.
    
    This APAR is targeted at WSRR v7.5.0.4 and v8.0.0.2.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IV37993

  • Reported component name

    SERVICE REGISTR

  • Reported component ID

    5724N7200

  • Reported release

    750

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-03-13

  • Closed date

    2013-04-18

  • Last modified date

    2014-03-19

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    SERVICE REGISTR

  • Fixed component ID

    5724N7200

Applicable component levels

  • R750 PSY

       UP



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere Service Registry and Repository

Software version:

7.5

Reference #:

IV37993

Modified date:

2014-03-19

Translate my page

Machine Translation

Content navigation