Moving from DEV to QAS MII - web service calls

[lawrence_prinsloo]

Hi all,

I'm curious if there's a better way of doing what I'm currently doing.  We have number of MII instances for DEV, QAS, etc...  MII is used as a central web service which all other systems call.  In some cases, this might mean that MII will request data from another system (via a web service) in order to fulfill the request.  These sub systems also have multiple instances for DEV, QAS, etc...

This means when I call the web services from MII, I need to be able to point to different servers - the DEV equivalent, or QAS equivalent, etc...  The way I've done this at the moment is to have a Global Parameter which defines the server path, then dynamically build up the web service URL for the web service action block in the MII transaction. Then I can point the Global Parameter to which ever server I want to call the web service on.

Is this the best approach or has someone out there encountered this and come up with a neater solution?

Thanks.

[former_member185280 · Accepted solution]

I have in the past stored url/ip address info in a JCo Connection defintion and pulled it out in my transaction with a JCo action that doesn't execute anything. Hacky but it works fine. It would probably be a good feature request to get the Connections configuration integrated with the web service actions.

Regards,
Christian

[lawrence_prinsloo · Accepted solution]

thanks.  Agreed, it would be a nice feature

[Former Member · Accepted solution]

Hi Lawrence,

Another option for storing parameters like this is in the Project Shared Memory object.  This may give a little more granularity on a per MII project basis, as these properties are visible from within the Project, and are transferred with the project as well.

Regards, Steve

[Former Member · Accepted solution]

Hi Lawrence,

I agree with Steve. Shared Memory is a neater approach in my view point.

Also you can change the values of the shared memory variables from admin screen and you don't need to open workbench.

Regards,

Rohit Negi.