This content has been marked as final. Show 6 replies
Its slightly confusing about having multiple projects, the reason being the way Interconnect works is that it has a single database repository and when you create a project it is just a view on that repository. Therefore a project and a repository are essentially one and the same.
Therefore it would imply that if you have 5 separate projects then you also have 5 separate repository instances.
In terms of your options:
1) is the general way that most projects work. Lets say you have DEV, SYS, UAT, PROD. Therefore you'd generally have a repository instance for each env, therefore 4 repository instances, HUBDEV - for DEV env, HUBSYS for SYS env etc... These repositories would usually be in separate Oracle Instances although they could be on the same servers. Therefore the Hub schema for all, would be the normal one installed by the product, OAIHUB904. Then you would also have a single project for each repository. This repository would hold all the metadata for all your interfaces that go though this HUB instance.
As interfaces move through the various phases then you migrate between the different repositories, to move stuff from DEV to SYS etc...
2) From my understanding, this is not much differnet to the above except you want to hold all the Hub schemas in a single database instance. This is possible by creating each schema with a differnet name, OAIHUB904DEV, OAIHUB904SYS etc... and you would need to change the necessary infrastructure ini files to use these new names. With this setup you would still have 1 project per repository but it would just point to the relevant schema.
Let me know if you have any more queries.
Thanks for the response.
With 'project' I meant 'integration scenario'. Some applications need to communicatie with several other applications. All of which is considered a seperate project. Each project has its own Development, Test, Acceptance and Production environment. This basically means 5 projects, 4 environments per project = 20 interconnect environments.
We want to reduce this amount to keep it maintainable.
Thing is, you can't just put all projects into the same repository. That would lead to troubles if you want to promote a single project from development to test without affecting the other projects. OAIIMPORT and OAIEXPORT make complete schema dumps, so ALL projects would get promoted. Not good.
Is there a way to promote a single project? I.e. exporting and importing only a certain amount of objects, while leaving the rest as is?
I'm still not 100% clear but i'll have a go and explain how I have used the product (on previous client sites)....
Generally speaking the Hub is considered a single Global system, that connects to a variety of other systems within a specific environemnt (can be DEV, SYS, UAT etc..)
If we look at the DEV environment then we have 1 Interconnect Project (for iStudio), 1 Hub schema (OAIHUB904) that stores all the interfaces for all systems.
Each adapter for this Hub will connect to the relevant Dev env for each of these applications.
If you only want to migrate a couple of Interfaces (publish/subscribe) messages into your SYS Hub env then rather than use oaiexport and oaiimport you use the Migrate function within iStudio. This enables you to select and interface or Application and specify a Source and Target environment and it will move any related interfaces through into that new Target Hub. Then when you open up your Interconnect SYS Project on the SYS Hub you will only see the interfaces that you have migrated. Likewise this approach can then be used to promote Interfaces into other environments.
Things to bear in mind are that Workflow, CBR rules, DVM's and XREF components do not get migrated and some element of rework maybe required or install scripts to populate these tables.
This should mean that you on have 1 Hub per Project Lifecycle (DEV, SYS, UAT, PROD) in this example 4.
Again, thanks for your reply Stuart.
- How would I migrate all the things that 'File -> Migrate' won't do for me? CBR, DVM, etc.
- If I have a project which has two applications (adapters) and one common view. Can I migrate them all at once? Like select the event, migrate and hey-presto?
Message was edited by:
Oh if only it was that easy......
When using migrate, you get a simple screen that lists all the Applications, you can either
- select the Application and migrate all the interfaces under that Application.
- or select each publish or subscribe event for that App. (this is obviously time consuming as for an interface you need to first do the publish event and then do the subscribe event as two separate tasks).
Both of the above will migrate all of the related objects (application data types, common data types etc).
When doing the migrate into an environment where the events exist already it prompts you that they exist and asks if you want to overwrite, it does this twice, once for the common view and once for the app view.
It generally works well however its always worth checking your target env to check everything has moved through as i have seen some things not work correctly.
It terms of adding CBR's and DVMs then I would do the following :
DVMs - these can easily be populated with a SQL script as the DVM is a simple database table.
CBR's - this is slightly more difficult, i'd say the only supported option is to enter it manually, however you could certainly create some SQL scripts.
Interconnect is a really good runtime tool and I've always managed to find a a way of doing what I need to do. However unfortuneatly there are a few issues with the managing it through the development cycle.
Thanks Stuart, for the information.