This content has been marked as final. Show 10 replies
yes you can use the existing SOA composites. But the request creation process in 11gR2 is through a catalog. So if you want to fetch the catalog details then you need to modify the code a little bit.
http://rajivdewan.blogspot.com/ (Get Catalog Details Associated With Request (Request ID)
for some info
What about Deploying and configuring the Request Webservice and configuring partner link? Do these are to be done for existing OIM 11gR1 workflows? Can you please tell me more on this?
Also, for existing workflows, below are the stages:
1. SOA composite creation using ant script
2. Develop workflows by adding global variables, java embedding activity, assign activity etc
3. Deploy the composite
4. Register and attach approval policies
Out of this, which stage changes happen during migration to R2.
Not needed for existing 11gR1 workflows as far as i know.1 person found this helpful
These are the steps in 11gR2
1. create a composite using ant script ( same as 11gR1)
2. Develop workflows by adding global variables, java embedding activity, assign activity etc (same as 11gR1)
I think you can reduce the code that goes into java embedding activity if you configure the partner link. The methods available in the partner link allow to fetch request details and catalog details without explicitly writing a java embedding activity. If you dont configure the partner link, well, u can write the code using api's as i mentioned in the previous post.
3. Deploy the composite ( same as 11gR1)
4. Attach approval policies . No need of registering it explicitly as it is registered automatically when you deploy it.
I have created a simple workflow to assign to user manager. I never configured partner link. It worked fine without any issues. So it is not manadatory to configure partner link explicitly.
Hope this helps.
Edited by: Durgaprasad on Feb 6, 2013 4:58 AM
Edited by: Durgaprasad on Feb 6, 2013 5:00 AM
Thanks so much for the inputs. Also, one more question I have, sorry for that. With context of up gradation, after upgrading to OIM 11gR2(not fresh installation), can I simply use the same deployed OIM11gR1 workflows/SOA composites with approval policies or need to redeploy it without any change. In case of change what will it be?
In my SOA composites, it has global variable declaration, Assign activity, Java embedding activity, Approval Task activity.Without any change to workflow or redeploying, can i submit a request after upgrading to R2?
Please let me know.
Sorry, I haven't tried migrating. May be you have to test yourself or somebody else in the forum who has the experience of migrating form R1 to R2 can give you the inputs.
11gR2 requires a new version of SOA. If you are going to updrade, i assume the steps say resolve all approvals. You will want to open your project in jdeveloper with the latest version that allows for the newest version of SOA Server and redeploy again, or deploy a new version.
Thanks DurgaPrasad and Kevin. What about existing connector integration in R1. Does that will be impacted during upgradation to R2. Can some provide brief note on this.
Your best option is to create an instance of your current environment and perform the upgrade. Then go through your test cases. There's always going to be different issues encountered, but if you spend some time and go through the upgrade process, and follow the steps documented, it should provide you with what you need and you will learn from your experience.1 person found this helpful
Yeah Kevin. Thats correct. Just a last question which is going through my mind. The request template is now removed from R2 and lot more changes with UI perspective. Then how can SOA composites will not involve much change according to below document
It talks about upgrading SOA composites. But in R2, we have catalogs, Application Instances etc and no request template. Now, just upgrading to OIM 11gR2 and redeploying the composites as mentioned in above doc will make work the request approval process?
That's a nice question.1 person found this helpful
We use Request Template mainly in Approval Policies.
Iff you are using anything related to Request Template in your BPEL workflow (code or some configuration) then you need to remove those things. We have created different Approval Workflows but we never used anything related to Request Template so in our case, we can upgrade that easily.