| Author |
Message
|
| sanathkumar |
 Posted: Thu Aug 11, 2005 2:00 pm Post subject: MQ Workflow V3.6 |
 |
|
Apprentice
Joined: 01 Jul 2003
Posts: 27
|
Hi
Currently we are using WMQWFv3.5. For developing process flows we are using WBI Workbench v4.2.4 FP3 and exporting them to FDL to import into Runtime of WMQWFv3.5.
Now we are planning to go for WMQWFv3.6 as we need to utilize API calls to Staff Administration. But my question is if we upgrade v3.5 to v3.6 , Can I still use WBI Workbench v4.2.4 FP3 for developing the process flows to import them into WMQWFv3.6 or Shall we need to go for any WBI Modeler v5.1.x?.
When I export FDL from WBI Workbench v4.2.4 FP 3 I have only option until MQ Workflow v3.5 there is no option of MQWF v3.6. Shall I need to install any FP to support that or I have to go for WBI Modeler v5.1.x to support WMQWFv3.6.
Suggest me if you have any manuals to explore more on this. Appreciate your help.
Cheers,
sanath |
|
| Back to top |
|
 |
| vennela |
| Posted: Thu Aug 11, 2005 2:07 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| 3.5 should be OK to work with 3.6 |
|
| Back to top |
|
|
| sanathkumar |
| Posted: Thu Aug 11, 2005 2:12 pm Post subject: |
|
|
Apprentice
Joined: 01 Jul 2003
Posts: 27
|
Hi
You meant to say that I can upgrade to v3.5 to v3.6 to utilize staff Administration API but still I can use WBI workbench v4.2.4 FP3 to develop process flows to import them into WMQWF v3.6.
I no need to go for WBI Modeler v5.1.x to develop process flows. Is that right?
Cheers,
sanath |
|
| Back to top |
|
|
| vennela |
| Posted: Thu Aug 11, 2005 2:40 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| I was meaning to say the FDL that works with 3.5 should work with 3.6 |
|
| Back to top |
|
|
| sanathkumar |
| Posted: Fri Aug 12, 2005 3:59 am Post subject: |
|
|
Apprentice
Joined: 01 Jul 2003
Posts: 27
|
Thank You.
Cheers,
sanath |
|
| Back to top |
|
|
| kotha |
| Posted: Fri Aug 12, 2005 7:17 am Post subject: |
|
|
Partisan
Joined: 12 Mar 2005
Posts: 333
|
| try importing the fdl you got into 3.6. or compare fdl from 3.6 with fdl of 3.5. you will get an idea if the fdl needs any modifications. |
|
| Back to top |
|
|
| sshaker |
| Posted: Wed Aug 31, 2005 12:04 pm Post subject: |
|
|
Disciple
Joined: 20 Sep 2002
Posts: 185
|
If ur too concerned, you may want to try changing the version info in the FDL to 36 after generating the FDL from workbench ! As stated earlier in the thread, 35 fdl should work with wf36 though !! Pl lets know how u make out.
_________________
shaker |
|
| Back to top |
|
|
| fidelio |
| Posted: Thu Sep 15, 2005 6:53 am Post subject: Re: MQ Workflow V3.6 |
|
|
Apprentice
Joined: 14 Sep 2005
Posts: 45
Location: AttainBPM
|
| sanathkumar wrote: |
| Now we are planning to go for WMQWFv3.6 as we need to utilize API calls to Staff Administration. |
Have you checked the architecture of the Staff Administration API against your needs? The API is architected to perform as a direct connect for a tool such as the LDAP bridge, and as such has some limitations built in to prevent update deadlocks, most notably the API is single-threaded - only one Staff Admin session permitted at any time. This restriction applies to the entire API, not just updates. So if you are planning on using the Admin API to do mainly searches - like finding users in a role - you might find that the performance isn't what you would expect. |
|
| Back to top |
|
|
| sanathkumar |
| Posted: Thu Sep 15, 2005 12:36 pm Post subject: |
|
|
Apprentice
Joined: 01 Jul 2003
Posts: 27
|
Hi
I agree with you regarding to performance if we try to access Staff Admin API concurretly. As we know, that only ADMIN can use the Staff API.
But our case we are going to use Staff ADMIN API for Creating new users , querying all users, roles , organization , adding roles to Users , delete the Users and adding VU_ authorization to Users from the custom GUI. For all these we will be using sigle ADMIN login to do the admin tasks.So will not effect much performance.
We already have in system that will pull users belongs to Specific Role and all users have authorized to VU_ gourps using "Emericon Utils". The only problem with this utils are we can not debug custom client locally(form DEV box). We need to change and test the application where the MQ Workflow is running. To avoid this, we are planning to utilize the Administration API where we can run them from locally to connect to Remote MQ Workflow (DB client is configured properly to remote runtime database).In this case, multiple users may login same time try to utilize Admin API through ADMIN login. This situation really we have to see how much performance we are facing.
We are now yet to decide the design for this. If you have any suggestion we are open to take.
Thanks for ur advise will keep in mind that.
Thanks,
sanath |
|
| Back to top |
|
|
| fidelio |
| Posted: Tue Sep 27, 2005 8:01 am Post subject: |
|
|
Apprentice
Joined: 14 Sep 2005
Posts: 45
Location: AttainBPM
|
| sanathkumar wrote: |
| In this case, multiple users may login same time try to utilize Admin API through ADMIN login. This situation really we have to see how much performance we are facing. |
sorry for the delay...
My understanding is that this multiple logins, even with ADMIN user, is not possible. The way the API was described is that there can be 1 and only 1 user logged in to the API. So if you have written a client using the Staff API that multiple people are using you will encounter problems performing Staff API functions. For example, if user1 is logged in and performing an update, and user2 tries an update, user2 will receive a "user already logged on" error. If the client is written so that it uses "force logon", client2 will successfully log on but user1's update might not finish properly since he was "logged off".
Unless the actual differs significantly from how the API was described at the T3, the only value it adds is that it allows for a single remote admin client to be developed. In an environment where you expect to need multiple users doing staff updates or queries, you are back to square one. I think the best way to do updates and queries is to have a seperate LDAP system which mirrors the WF database using the LDAP Bridge, but this has the obvious weakness in that you won't be able to make real-time updates.
If you need real time updates, I don't see a way around something like the Emericon Utilities. |
|
| Back to top |
|
|
|
|
