Fix Department Import Job

[rmaroti]

The department import job running via powershell seems to be broken since 08/2024. It needs to be analyzed and corrected.

Analysis so far:
-There is the scheduled job which is executed every Monday at 6 AM CET. This one calls the one subflow.

-The Subflow generates a Command for the MID server in the ECC queue table (ecc_queue), with a hard-coded MID server name as the Agent.

-On the PROD environment this generated record is never processed, but stays in the queue in the state ready.

As the provided MID server does not exist, the command is not picked up and remains in the queue. Initial solution suggestion:

 Need a solution like below -
1)How to create a dynamic way to determine the MID server within the flow, either by querying the MID server table within the flow, to pick one, which is actually up.

2) OR store the responsible MID server name/sys-id in a system property, which is queried in the flow. So, it can fix the issue.

Could you please find the below attached screenshot of scheduled job subflow and queue record. and give me the solution.

[Vasantharajan N]

@rmaroti - Just follow the below steps to make it configurable.

Step 1: Create a System Property say "import.department_data.mid_server" and set the value of the actual Mid Server where you have the powershell script.

Step 2: Update your subflow to populate the Agent value from the System property that we set in Step 1.

var agent = gs.getProperty("import.department_data.mid_server");
return agent;

The result after doing the change will be having the job submitted to the right mid server which are different for each environment.

[rmaroti]

@Vasantharajan N  - In mine case which one is need to set the value of the actual Mid Server where you have the powershell script?

Can you please see attached screenshot and below value and let me know which value i need to set in system. properties value.

1) mid.server.cariaddev_sobdev - this is agent field value in subflow

2) var value ="powershell .\\scripts\\PowerShell\\cariad_structure_data.ps1"; - this is payload field script in subflow.

[Vasantharajan N]

@rmaroti - In your subflow its hardcoded which is causing the failure when you move the code to Prod. The solution I've recommended will take the mid server name from a new system property.

In your case, you need to set the system property value to the mid server that is connected to your Production instance. 

[rmaroti]

@Vasantharajan N  - Any update on my above concern ?