Keep in mind, scheduled processing rules don't have a client to which to respond. Therefore, they must operate totally on their own.
In your case, replace the route action with a results action setting the destination to 'var://context/EBC/url' as in the picture. Then, follow the results action with whatever actions are needed to handle the response. I threw in a transform action as an example, because I have no idea what the response looks like or what type of message it is. See the 2nd image.
Original Message:
Sent: Sun August 27, 2023 06:18 PM
From: Riham Lamei
Subject: Scheduled Processing Policy Rule
I have tried the mentioned solution with no luck to reach the backend successfully.
So appreciate your effort and support in guiding us to trace the headers, as we tried to display the headers in the logs but it shows as undefined(from schedule/XML Manager).
Although we succeed in sending the request from postman and displaying the headers in the system logs.
Kindly if there is a way to track the response(from the schedular side) will be highly appreciated.
And many thanks for the constant support.
------------------------------
Riham Lamei
Original Message:
Sent: Thu August 24, 2023 12:32 PM
From: Joseph Morgan
Subject: Scheduled Processing Policy Rule
So, just looking at the rules and XML Manager provided, I noticed the back end is "https". When you run this, say, through a service, I suspect the TLS client or profile is defined at the service level. But when the rule is scheduled by the XML manager, there is no TLS client or profile defined.
Therefore, my recommendation is to define the TLS client or profile to the User Agent's TLS Profile Policy of the XML Manager.
Of course, create a new user agent, maybe also named "Daily_Key_Timer", and define the TLS Profile Policy there. Add a new policy and set the URL Matching Expression to "*/ipn/1.0". Set your Proxy Profile or Client Profile (whichever type you are using), and save it.
Let me know how it goes.
------------------------------
Joseph Morgan
Original Message:
Sent: Thu August 24, 2023 08:18 AM
From: Riham Lamei
Subject: Scheduled Processing Policy Rule
Yes a value settled by "savePreAuthData.xslt", the fetch is just for logging.
for simplifying the flow: First Gateway Script is for structuring the request body.
Second XSLT is for setting the backend URL and adding headers(how can i add headers in the xml manager itself/ user agent object).
Then Signing the Request.
After that routing the request to the needed backend(at which it's value is settled in the xslt).
Appreciate your support.
------------------------------
Riham Lamei
Original Message:
Sent: Tue August 22, 2023 10:20 AM
From: Joseph Morgan
Subject: Scheduled Processing Policy Rule
Where is the back end failing? To the value set in the requestURI within "savePreAuthDta.xslt", or is it the fetch from the EG_IPN_PRE.AUTH queue?
------------------------------
Joseph Morgan
Original Message:
Sent: Tue August 22, 2023 08:52 AM
From: Riham Lamei
Subject: Scheduled Processing Policy Rule
yes the outbound URL is the same.
kindly find the xml manager and the business rule.
------------------------------
Riham Lamei
Original Message:
Sent: Mon August 21, 2023 09:14 PM
From: Joseph Morgan
Subject: Scheduled Processing Policy Rule
>> I'm exposing same rule in the processing Policy so I can either call it from the processing policy or it is been called by the xml manager.
That's exactly the way I do it. Makes it easier to build, maintain and test.
So, let's break it down.
When you says you "checked the URL and request body", how can the URL be the same for the scheduled rule? Are you talking about the outbound URL?
What does each action on the scheduled rule do? (If you can export and attach, might be quicker for me to drop it into an appliance and look for potential problems).
------------------------------
Joseph Morgan
Original Message:
Sent: Mon August 21, 2023 08:24 PM
From: Riham Lamei
Subject: Scheduled Processing Policy Rule
I'm exposing same rule in the processing Policy so I can either call it from the processing policy or it is been called by the xml manager.
I have Checked the URL and the request body they are the same exactly.
but I still can't check the response body coming from the XML Manager so is there a way to check the response?
In addition I captured the packets but I found out that no requests are sent from the xml manager.
------------------------------
Riham Lamei
Original Message:
Sent: Mon August 21, 2023 06:41 PM
From: Joseph Morgan
Subject: Scheduled Processing Policy Rule
So, how do you call the rule from PostMan or otherwise externally?
That is, my guess is the rule may somehow depend upon something coming in from the outside, like maybe the URL, or some setting that changed in the service, such as propagate URI. The scheduled rule doesn't get any external client initiated information. That's the change you're seeking.
I would definitely look at the PostMan invoked probe and check any variables the rule uses that will not have the same values if the rule executes without an external actor.
You're likely going to have to write some additional logging (either through the XSLT/GWS) or actions in the rule, or all of that to find out.
------------------------------
Joseph Morgan
Original Message:
Sent: Mon August 21, 2023 06:17 PM
From: Riham Lamei
Subject: Scheduled Processing Policy Rule
Hello,
I'm using the Scheduled Processing Policy Rule in the xml manager. It was working fine but suddenly, I found that it stopped reaching the backend it was calling.
Although no errors occurred on the logs and calling the rule separately from the postman no issue occurs and it reaches the backend as usual.
Adding the user agent did not fix the issue.
So I tried to replace the route and result nodes with a fetch node it shows that there is a connection error. so I returned back the route and result nodes.
Appreciate your feedback, and details to see the request flow over probes.
------------------------------
Riham Lamei
------------------------------