Asynch AppServer calls in Dynamics

asthomas schrieb:
...
For this all to work properly, should I not have 2 different handles, one for the asynch calls and one for the synchronous calls?
...

Absolutely. You need to have two different handles to be able to run two request in parallel (one sync, one async).

In the case we discussed earlier I was not using the connection manager for establishing the connection used for the async processes (I just reviewed that solution - I do't remember the reasons anymore but they may be similar to your findings).

I'd report it to tech support to get it fixed. Did you try if adading the logical service name to the function call solves your problem? If you need a quick solution, I recommend establishing the connection manually. You may use a session property to still define the appserver URL in the icfconfig.xml file.

Got it.

After looking through the code, it turns out that the AppServer Connection Manager is coded to look for existing connections to the same AppServer, completely ignoring the logical service name being passed in. The code is written to re-use connections to the same physical AppServer when a connection request is made.

The result of this is that when I try and set up 2 appserver connections, with different service names, I get 2 handles set - but with the same value!

I have worked around this by avoiding the check for the existing physical service - and this seems to do the trick. So now asynch AppServer calls work as they should with Dynamics.

In case anyone is interested, the code I showed before should be replaced with the following:

hServer =

WIDGET-HANDLE(DYNAMIC-FUNCTION('getServiceHandle':U IN THIS-PROCEDURE, INPUT pcServiceName)).

If the service is not connected, then the rest of the existing code does what it is supposed to do and connects to the service with the correct name.

The ADM2 seems to do a similar thing. I guess it all still comes from the idea of developing the application with as many "appserver partitions" as product modules. At runtime those may all go to the same appserver partition - but you are futurte proof in case you need to spread the load for the finance module to a different server than the order processing...

Having seen a large number of ADM2 and Dynamics applications, I haven't seen anybody using logical partitions in that way.

Are you willing to share your fix? :-)

I described the fix in the last comment I made :-)

Attached is the AppServer Connection Manager with the fix in it.

This is the 10.2A01 code - but it has not changed in a long time.

First some background:

We can have one or more Dynamics physical services pointing at one or more actual AppServers, running on actual machines, each with a different name:

(/me likes shiny New PSDN editing)

We can also have one or more Dynamics logical services, each with a different name:

After looking through the code, it turns out that the AppServer Connection Manager is coded to look for existing connections to the same AppServer, completely ignoring the logical service name being passed in. The code is written to re-use connections to the same physical AppServer when a connection request is made.
The result of this is that when I try and set up 2 appserver connections, with different service names, I get 2 handles set - but with the same value!

I have worked around this by avoiding the check for the existing physical service - and this seems to do the trick. So now asynch AppServer calls work as they should with Dynamics.

If you want different handles to the same machine AppServer, you need to set up different physical services in Dynamics.

Having seen a large number of ADM2 and Dynamics applications, I haven't seen anybody using logical partitions in that way.

I need to point out that this change was made specifically for a customer   They wanted to use multiple Dynamics logical services with one physical Dynamics service. If your fix were implemented, it would break that customer's app (your change reverts the behaviour back to the original behaviour).

HTH,

-- peter

Message was edited by: Peter Judge.
Finish post. Seems like CTRL-S works as it does on the desktop

Which brings me to another idea for Thomas:

How about using different AppServer connection parameters for the same AppServer instance? Just add two Application Service names to the same AppServer instance in Progress Explorer/OpenEdge Explorer.

- assync

- asasync

The Dynamics application would have absolutely no chance to identify the different connection parameters

-H servername -AppService assync

-H servername -AppService asasync

as the same physical AppServer instance.

Would that work for you??? It will also allow to move the async requests (typically long running processes) to another server machine later so that it would not affect the performance of the synchronous appserver calls (used in interaction with the user).

Mike

- assync
- asasync

Actually I'd rather use two names that are easier to distinguish...

I think the way it sounds like this is supposed to work is misleading. (I had to debug the code to get to understand how it works ) I would expect that if I change the logical name of the service, that this would also give me a different handle. I suppose the best thing would to have a property on the service so that you can choose if you want a new handle of want to re-use existing handles.

If this is by design for a customer that wanted to have different logical names using the same handle, how would you then implement the asynch setup my customer wanted ?

... I just saw Mike's suggestion which would probably work...