Skip to main content

Dear Community,

At a PSO instance 6.9.0.18 which is hosted by IFS Cloud Services connected to an IFS Cloud environment (23R2) also hosted by IFS Cloud Services.

The Scheduling Optimization Configuration is successful with the “4 blue OK messages” when saving. Also when Testing, the response is within 2 seconds “Connection successful”.

When sending a dataset, the background job is OK, and when looking at the Application Message created, that status is "Released”. There is an Input Message Data XML which is the LOAD XML and looks fine to me. But there is not Output Message Data XML.

When looking at the PSO in the Event Log, we don't see any action here… 
I am an admin, I have full permission in both Cloud as PSO. 

Does anybody has any ideas where to investigate, push or fix stuff?

 

Application Message:

 

PSO Event Log:

 

Hello Mr. Segers! Hope you are doing fine! :)

Can you please try to enable the user sync and create an IFS cloud user with one of the pso permission sets and then sync the users dataset (via “send reset” on the scheduling datasets screen)? Just to test, if that works. If yes, maybe there is an issue with the basic data setup inside IFS Cloud? I assume you don’t see any recent errors/warning inside the pso events?

Best regards
Roman


Hi Roman! :)

User sync have been on and off, will check that. Also will re-check the basic data. It has worked before but there might be a chance someone changed it… I'll dive into it, thanks!

Cheers,
Stephan


I had a very similar situation on a 23.2 instance last week (outbound application message did exist, no response from PSO, no LOAD audit in PSO). Could not resolve this even as admin, turned out it was an infrastructure issue. Once that was fixed, PSO sync went back to normal operations. Hence I would suggest opening a ticket.


Hi @Alexander Heinze ,

Being it you with a similar situation gives me a bit more confidence it's not just me being stupid :)
Created a ticket as we speak, thanks! Ticket id is CS0235369. Would you be able to provide your ticket id, so support has more information to fix it. 

@roklde, checked users which is OK, checked basic data but haven't found an anomaly yet.

Cheers,
Stephan


Hi @Alexander Heinze ,

Being it you with a similar situation gives me a bit more confidence it's not just me being stupid :)
Created a ticket as we speak, thanks! Ticket id is CS0235369. Would you be able to provide your ticket id, so support has more information to fix it. 

@roklde, checked users which is OK, checked basic data but haven't found an anomaly yet.

Cheers,
Stephan

Unfortunately I don’t have a ticket ID as our internal environments are managed and supported differently (plus I was not the owner of that instance).


In the end it was caused due crashing pods on the IFS Cloud side. IFS R&D had some checks and will prevent these situations in future releases.

There were XML files over 1GB size created due to unknown reasons.


Reply