Separated queues to differentes processes

[Former Member]

Dear Experts,

We have a 2 scenarios, each of them with its own group of Intefaces, and I have the requirement that each of scenarios shoud have its exclusive queue or queues for processing the messages.

The messages of the two scenarios have the same priority, therefore I guess I can't use the priorization of messages. This could imply that the messages of one of the scenarios will have higher priority than the others, with the problems of this could cause.

Somebody knows any way to do this?

Any help will be appreciated.

Thanks and regards,

MML001.

[former_member181962 · Accepted solution]

You can use the EOIO option in Quality of service of the communication channel and specify different queue names for different scenarios.

Best Regards,

Ravi

[Former Member · Accepted solution]

Dear Ravi,

Could you elaborate your response, please? How can I asign the queue name?

Thanks and regards,

MML.

[MichalKrawczyk]

hi,

>>>We have a 2 scenarios, each of them with its own group of Intefaces, and I have the requirement that each of scenarios shoud have its exclusive queue or queues for processing the messages.

why ? you did not mention the reasons just a solution

queues in PI processing will not give you any priority for message processing

from my point of view the requirement is not clear - why do you need to have exclusive queues ?

using EOIO will have a heavy impact on your message processing (issues with error processing etc)

describe why do you need those queues and we may be able to help you,

Regards,

Michal Krawczyk

[Former Member]

Dear Michal,

My client wants each of scenarios has exclusive queues, to, among in others reasons, in case of errors and locked queues, the execution of messages of one of the scenarios don't impact the execution of messages of the other scenario.

I refer to the priority of the messahes because I have seen that one of the solutions proposed to this case is setting queues with high priorize, and I don't know this be a solution to my.

I hope this will clear the question.

Thanks and regards,

MML.

[MichalKrawczyk]

Hi,

then ppriority should be your solution and not different queues

if you start using EOIO (with queue assignment) your interfaces will not be locked

in different queues but once the error happens in any of those queues the whole interfaces will be locked

alternatively you can use content based queue assgnment (so that your two scenarios will use

exclusive queues but many of them - for example for each partner/customer a different one)

then the issues in case of errors would be much smaller

(there are multiple blogs on SDN on how to build Amodule for content based queue assignment)

to conclude

don't push them with EOIO in one queue-per one scenario (use content based queues if you need to use EOIO)

Regards,

Michal Krawczyk

[Former Member]

Michal,

If I use the priority, this means that the processing of messages of the scenario with higher priority will impact on the processing of the messages of the other scenario.

My client doesn't want that the messages of a scenario, caused by its higher priority, impact on the other scenario, by example, slowing down the messages of these lower prioriry messages.

I hope I have been clear.

Thanks and regards,

MML.

[MichalKrawczyk]

Hi,

then try going for my second solution - content based queues

Regards,

Michal Krawczyk

[Former Member]

Hi MML,

To synthetize, if SAP did not change recently its queue process, you have three choices:

¤ Choice 1: precise nothing. So PI will choose itself and randomly the queue to be used.

¤ Choice 2: use EOIO (exactly once in order = asynchron by respecting the sequence)

For that, in CC, we give a queue name (hard-coded) which will be used for ALL the exchanges of this interface. And as PI queues run in FIFO (First In First Out), as Michal said, if you have an error it's the whole queue which is locked with an impact of ALL further exchanges of this interface.

a variant of Choice 2: if you want to manage dynamically the queue name (instead of hard-coded in CC), you have to develop a "queue based content" in a module (e.g)... But it's still an EOIO exchange !

¤ Choice 3: use message prioritization. to limit (a litle) the randomly choice of PI.

so the real question that your client has to answer is: does he accept to have ALL exchanges of an interface which are locked in PI because of ONE message of this interface (when something is wrong) ?

if yes, EOIO is the solution, with or without its variant "queue based content".

if no, the only way to specify (a litle) a queue in PI is message prioritization.

Regards.

Mickael