Thanks for replying Craig. Seems to be an unpopular topic!

I understand that with MSMQ. But Events (persistent subscriptions anyway) DOES make allowance for the HRESULT return code. The problem is that the current implementation is next to useless when you have more than 1 subscriber. It is this that I'd like to find out HOW to get changed via ER to the proper place.

As I see this feature (and of course I could be wrong) it has tremendous potential to CHANGE HOW WE DEVELOP AND DELIVER FEATURES - for the significnat better - if a little bit more logic could be integrated into the base feature for return code handling.

The simplest thing that comes to mind is that one could deliver and install the "main application controller" component that would simply almost be a series of COM+ Event publications. This part need hardly ever change. Then other components of the system would be developed/tested/delivered as subscribers. This gives amazing development flexibility and also significantly expands the kinds of features that can be offered to users, USUALLY WITHOUT TOUCHING any operational code!!!!
Some of these subscribers would necessarily be CRITICAL for the application functionality. Since the publisher component would be the "mainline", it would have to clean things up and halt processing (or whatever makes sense) when such (critical) components fail.

While returning only HRESULT is rudimentary, it can likely be just enough to make a scheme like this work. Remember, we can pass (by value) parameters TO the subscribers (same go to all).
But to make it work we need to be able to ENSURE that any FAIL HRESULT gets back to the publisher. At least a FAIL in a critical component.

The SUBSCRIBER items already have a PROPERTY sheet available to them. I could see an item being added there, for use by the COM+ publisher controller, to make this happen.
That would be a check-box to indicate if the HRESULT from THIS subscriber matters or not.

The COM+ publisher controller would initiate then ignore all subscriber where the property says it doesn't matter. On the other hand, for those that do matter, the COM+ publisher controller would WAIT for each of them to complete BUT could return a "FAIL" HRESULT as soon as any one of these completed with a FAIL HRESULT. IF the last one (that matters) completed with SUCCESS, then it would return success (it would already have returned a FAIL if a failure had occurred in another of the subscribers.

This looks eminently DOABLE to me and I see HUGE potential for it.

Without this it looks to me like this would be a (partial) feature going to waste. With this it opens up application development and delivery to a new level.

There might also be another thing that needs to be enhanced within the same feature.
When I made the test of 2 subscribers I changed the existing subscriber (directly from the sample). When I added another subscription I noticed that the original was no longer (apparently) a subscriber. I guessed that it had been removed because it had been recompiled (with a change that affected the component's "signature", since it now returned HRESULT).
There would need to be some kind of warning for such a condition, else it would be far too easy for subscriptions to get UNKNOWINGLY dropped.

Jim



>You have to use COM+ Events and Queued Components in situations where you don't care about getting a return value. For example, you could spin off a lengthy report process and then email the results or have the user come back later.
>
>If the return value is important to you, don't use COM+ Events or Queued Components.
>
>
>>Craig,
>>
>>I understand that.
>>
>>My concern is that Subscribers can ONLY return a HRESULT (which by itself is just fine) but if there is more than 1 subscriber then *ANY* HRESULT (of COM+'s choosing, apparently) is returned RATHER THAN a "FAILED" HRESULT if 1 of the subscribers fails.
>>
>>I can't see, therefore, how I can consider this 'model' for mission critical components, because if 1 of several FAILs then there is likely NOT a return to indicate that fact (any "SUCCESS" HRESULT) is more likely to be the one).
>>
>>I started another thread this morning asking how/where to submit a ER to get this changed. I believe that there is great merit to the publisher/subscriber (persistent) feature, but only if any FAIL HRESULT can be GUARANTEED to be the one returned to the publisher.
>>
>>Do you know where/how to do this? Is this something that I should try to convince the VFP Team of its merit and then they can submit it?
>>
>>Jim
>>
>>
>>
>>>Jim,
>>>
>>>You only inherit the interface from the the parent class. The implementation is in the child classes.
>>>
>>>>I can see dealing with failure on the publisher side. I think I have a few options there.
>>>>But it is the subscriber that troubles me. I don't see how I can tell that it completed (heck, I don't even (seem to) know that it was even run), let alone completed successfully. Writing to the event log will let a person see that there is trouble, but what about the application? Looks like I can only use this for application bits that are irrelevant to the main processes. Sort of like 'nice to haves' and 'hopefully most of the times it will run' kind of things. I really haven't done many (none, really) like that.
>>>>
>>>>I really think I must be missing something basic here.
>>>>
>>>>Jim
>>>>