[otmrookie]

Hi all,

We currently have multiple instances of EBS(each for a business sector), and intend to implement 1 instance of OTM. Has anyone tried integrating the many(EBS)-to-one(OTM) instance before? We understand that a one-to-one instance is not an issue. But we'd like to explore our options, perhaps the domain/sub-domain in OTM can alleviate some of our integration concerns.

[rafikki]

I think diffrent domains will work well. You won't be able to use the standard integration though. (But I don't really reccommend it anyway)

Marinus Snyman

[otmrookie]

Hi Marinus,

Do you mean multiple domains or multiple sub-domains may work? Our understanding is that multiple domains will work within a single OTM instance but multiple sub-domains (along with a parent domain) will require customization due to the information that need to go back and forth between each EBS instance and corresponding sub-domain.

[rafikki]

I'm not sure I understand what you mean. But what I mean is that you can spesify in the integration to which domain the info should go to (whether its a domain or a subdomain)

So you can have a domain for each EBS instance, for all the data. (Including master data, orders ect) You can also have a master domain for all the master data, and subdomains for all the transactional objects (orders ect..), but my worry of this method would be that the ID's of the master data will clash between the diffrent EBS systems in OTM? (Thus something like you will have 2 or more Customers with id "123"

Also for data going into OTM you would be able to use the standard integration because you can spesify the OTM-domain in a profile option in each EBS system seperatly. But for info going back to EBS, you can only set 1 IP/port combination for the BPEL flows.

Another thing you might want to consider is do the EBS systems have multiple ORG's? If they do, you might want to consider subdomains in OTM for the diffrent ORG's?

Hope it make sense, if not let me know.

Also, keep me up do date with the project, it sounds quite interesting. Where about are you doing this?

[chrisplough]

Yes - this is definitely possible -- in fact we've implemented it this way for a client already here's how it works:

You configure each OTM instance to utilize a different BPEL Domain (patches required) and to then point towards a different OTM domain. On the OTM side, you setup different external systems and web services within each domain, to point back to the respective BPEL Domain and EBS instance.

So, in the end, you have multiple EBS instances, one BPEL instance with multiple domains, and one OTM instance with multiple domains.

Now, this will work with the standards EBS/OTM integration provided by Oracle. However, whether that pre-packaged integration meets your needs is another issues. I'd recommend a careful gap analysis, as custom integration can often work better and reduce the implementation time.

Thanks,
Chris

[otmrookie]

Thank you Marinus and Chris for your input. We would like to stick with the pre-packaged integration as much as possible for future ease of support and maintenance reasons. Having said that, if we do end up having to customize at the BPEL integration layer what are the ramifications as far as putting on future OTM/EBS patches are concerned? Will we have to re-tweak our custom integration based on what the patches contain? Or is it safe to say Oracle's patches are always non-integration specific, just feature enhancements or bug corrections?

[rafikki]

I don't really know about the oracle patches, maybe Chris can help? I do however urge you to look closely and see if the standard integration is the best way to go for you guy's.

[chrisplough]

As far as patches, it depends. For standard patches to either EBS or OTM, it shouldn't make a difference to your integration at all -- though I'd always recommend testing in a dev, test or pre-prod environment.

However, when Oracle releases patches to the pre-packaged integration flows, and you've customized them, then you'll need to own the process of merging those changes into your customized flows. While I understand your desire to use only standard integration, to ease future maintenance -- I don't believe the integration flows are mature enough to allow that. I'm not aware of any client who's been able to use the integration flows without modification.

--Chris