Troubleshooting

Overview

This section provides step-by-step instructions on how to resolve common issues experienced when using Production Scheduler.

Prerequisites

Before trying to resolve any Production Scheduler issues you must have the correct versions of Sage X3, Production Scheduler and the Production Scheduler mapping data installed.

The following table lists the current requirements for each post patch level.

Sage X3 delivery/Production Scheduler: List of elements needed for Sage X3 by Sage X3 version

Sage X3 patch level Production Scheduler version Transformation mapping data version

Unique attribute of mapping
(Mapping code - X3 alias)

V11.0.1

6.0.1651

ProductionSchedulerMappingData-V2

Any records

V11.0.2

6.0.1651

ProductionSchedulerMappingData-V2

Any records

V11.0.3

6.0.1651

ProductionSchedulerMappingData-V2

Any records

V11.0.4

6.0.1705

ProductionSchedulerMappingData-V3

POPSENVDET - MATFIXDAT

V11.0.5

6.0.1723

ProductionSchedulerMappingData-V4

POPSENVDET - CUSVAL

V11.0.6

6.0.1739

ProductionSchedulerMappingData-V5

ProductionSchedulerMappingData-V6

POPSENVDET - PRVWOID

POPSENVUPDEDIT - STROPEDT

V11.0.10 / V12.0.3

6.0.1829

ProductionSchedulerMappingData-V6

POPSENVUPDEDIT - STROPEDT

V11.0.11 / V12.0.15

6.0.1842

ProductionSchedulerMappingData-V6

POPSENVUPDEDIT - STROPEDT
See also

Appendix 1 to check your version of Production Scheduler.

Appendix 2 to check the current mapping version.

A mapping check is performed when entering the Production Scheduler function (FUNPSSCH). This functionality is available from V11 patch 12 and V12 patch 16.

Troubleshooting 1: Site not initializing

There are a number of reasons why it may not be possible to initialize a site in Production Scheduler. Some of the most common reasons are detailed below.

You should report your issue if you cannot resolve the issue from the following information.

Our example is a generic error so we need to look in detail at the logging information.

  1. We look at the time of the error and locate this time in the log. In our example it is 10:16:16 on 02/02/2018:

  2. By looking backwards from the error time, we can see another error, Agent cannot be null, and a warning, Unexpected property sev/mess in environment.
    1. The significant message is the Unexpected property.

      This happens when Production Scheduler receives information it does not know how to process.

    2. The significant part of this message is the sev and mess.

      3. These are errors messages from Sage X3, but not the actual error.

  3. To view the actual Sage X3 error we must use a different tool.
  4. Using Postman, we can see the mess and sev elements that Production Scheduler does not recognize. However, the actual error message is a transformation error.

      Transformation errors suggest a mapping problem.

    5. We go to the section Issue with mapping data.

Identifying the issue

  1. Check the Summary tab in the Production Scheduler Manager.
  2. If a site will not initialize in Production Scheduler there can either be an error, or a warning against the Production Scheduler ERP Adapter.

Invalid configuration information

  1. To see if there is a connection error, first check the Configuration Manager tab.
  2. A warning icon (red) shows that Production Scheduler is not able to contact Sage X3, therefore the information provided must be incorrect.

    • Is your Windows username and/or password (Sage X3 username and password) invalid?
    • Is the server name incorrect?
    • Is the REST services port (Sage X3 port number) or instance (Sage X3 folder name) incorrect?

The Sage X3 port number (REST services port) is 8125. We check the Configuration Manager tab. We can see it should be 8124.

We make the correction and can see that a check icon (green) is displayed confirming the connection is working.

No access to Sage X3 (can depend on start-up process)

This issue is similar to the previous issue (Invalid configuration information). However, the reason is different.

  1. Check the Configuration Manager tab to see if there is a connection error.
    1. A warning icon (red) shows that Production Scheduler is unable to contact Sage X3.
    2. An information icon (orange) shows that Production Scheduler cannot verify the server connection.

      It could be that Sage X3 is unavailable because it is still starting.

    Correct the start-up sequence of the servers so that the Production Scheduler server is the last to start.

A user does not have access to the specified Sage X3 folder (LOCALDEV). Production Scheduler is therefore unable to retrieve any data.

We check the user permissions for the folder (instance) and correct the folder name or the permissions.
You might need to restart the service for the changes to implemented.

Connection to Sage X3 but still not initializing

Having checked the connection information, Production Scheduler can talk to Sage X3 but the sites are still not initializing.

  1. In order to understand the issues, click the Production Scheduler Logging tab.
  2. Once the Production Scheduler service is running, you can choose which log to view.

    3. It is best to select the PlannerOneApplication.log as this is the latest log. This log contains all information, not just errors.

  3. Click Open/Refresh log.

  4. The log is now open, however the oldest information is listed.
    1. To see the most recent information click the Follow tail check box.
    2. To view up to date information click the Auto refresh check box. This updates the log with new information automatically.

    Be careful as it is not possible to navigate through the log when Auto refresh is enabled.

  5. The log information shows only general information, no errors.

  6. The quickest way to see errors that have occurred is to look at the Error list tab. This gives a brief description of the error.

  7. Click the error to see more detail.

  8. Click the double chevron (>>) action to obtain even more information.

This might be enough to determine the source of the problem.

We may get other errors that point to a problem in the code or user permission problems.
See alsoAppendix 4 > Using the Postman application to identify problems

Issue with mapping data

Having identified an issue with the mapping data there is a simple fix.

Integrate the correct patch version for the version of Sage X3.
The table in Troubleshooting > Prerequisites details which version of the mapping data to patch for the version of Sage X3.

 

Once you have updated your system with the correct version of the mapping you should have a working system.

Problem in the code

Sometimes there is an issue in the code which results in a site in Production Scheduler not initializing. This is rare as most issues have already been fixed.

There may, however, still be issues that have not yet been discovered.

  1. Code problems can look very similar to mapping issues in that you get a similar warning - sev/mess unexpected property in the log file. Identification of the problem is the same.

    You can try the Postman application to identify problems.

  2. Sometimes the error provided is not detailed enough.

    You can use Postman with an internal request directly to Sage X3 to give more details.

This gives us the exact error and the script and line on which it occurs.

Troubleshooting 2: Cannot access Production Scheduler from Sage X3

Normally, you would access Production Scheduler using a Sage X3 function such as the Production Scheduler function (FUNPSSCH) (Manufacturing > Production Scheduler > Production Scheduler).

If this functionality is not working you must observe the problem, then investigate it.

In this section we show you how to detect and resolve likely causes of being unable to connect to Production Scheduler.

The port number of our instance is 9990.

We check the Production Scheduler Manager. We can see it should be 9120.

We correct the information.

World Wide Web Publishing service not running

To check if the World Wide Web Publishing Service is running, open the Services program.

Check the Status of the World Wide Web Publishing Service. It should be set to Running.

If it is not running, which is common on template VMs (such as those used by partners), start the World Wide Web Publishing Service.

Production Scheduler web site not running

If you now have a Cannot get or validate token error, the website for the instance might not be running.

Check Internet Information Services (IIS) Manager for the instance website.

If the website is not running, start the website.

Production Scheduler service not running

If you still have a Cannot get or validate token error, the Production Scheduler service might not be running.

  1. Check the Summary tab in the Production Scheduler Manager.

  2. If the Windows Service is at status On error (red), check the Windows service tab to see if there is a problem, or if the service is running.
  3. Select the correct service for the instance and click Select.

    4. If the status shows that the service is stopped, start the service.

PSCLIENTID parameter not set

If you have the Information message: Unable to obtain authentication token, Sage X3 cannot create the authentication token to send to Production Scheduler.

This means that the client ID is missing or invalid.

  1. Check the PSCLIENTID – Production Scheduler client ID parameter (EXAPP chapter, MIS group).

    2. Make sure that in the List of connected applications in the Connected applications function (Administration > Administration > Settings > Authentication > Connected applications) the Client ID matches the one for this tenant.

Incorrect connected application data

If you now have the error: Production Scheduler took too long to respond.

Check that in the List of connected applications services in the Connected applications function (Administration > Administration > Settings > Authentication > Connected applications) the URL is correct.

 

Production Scheduler should now be working.

Troubleshooting 3: Data flow from Sage X3 to Production Scheduler

Once everything has been setup correctly data can be sent from Sage X3 to Production Scheduler. However, there can be issues resulting in some work orders not appearing in Production Scheduler.

In this section we show you how to detect these types of issues and how to resolve them.

Where an example tracks an issue through to a resolution, sequential numbers indicate a continuation of the same example.

For our example two work orders - WO000119 and WO000120 - have been submitted to Production Scheduler.

The work orders are not in Production Scheduler.

We track these missing work orders through this section.

Standard guidelines for missing work orders

If there are missing work orders in Production Scheduler and it is not clear which work orders are causing the problem:

Remove all work orders from Production Scheduler, then reintroduce them one by one.

If there are too many work orders, introduce them in small batches to narrow down the work orders causing the problem.

Invalid data in Sage X3

If there are missing work orders in Production Scheduler, data in Sage X3 could be incorrect.

  1. Check the Summary tab in the Production Scheduler Manager.
    1. The Production Scheduler Manager is reporting all items are at status Ready (green).

      2. It is normal for the Resource Planner ERP Adapter to remain at status Unknown (question mark).

    2. Windows Service Errors are listed.

      3. These must be investigated.

    Our example shows 26 Windows Service Errors.

  2. To see what the Windows Service Errors are look at the Error list.

    Our error list references WO000119 and WO000120. These are our missing work orders.

  3. View the error details.

    4. The error explains that there is a missing resource: Resource does not exist.

    The R_ is added by Production Scheduler.

    Our example shows a resource called MISSING does not exist.

  4. Check if the missing work orders use the missing resource (work center).

    5. Our missing work order WO000119 does use the work center called MISSING.

  5. Check if the missing work center is a valid work center.

    6. Our example shows work center MISSING is not listed.

This is why Production Scheduler has an error.

  1. Now check all other work orders for any that use the missing work center.
  2. If the other missing work orders do not use the missing work center you must investigate further.

    3. Our example has the same error message for work order WO000120.

    We check the work order. It does not use the work center MISSING. We must investigate further.

  3. Check each work center used on the missing work orders.

    4. Is the missing work center defined as a Replacement work center?

    Our example uses MISSING as a replacement work center.

    Sage X3 sends all replacement work centers as alternatives when scheduling, so this produces the same error.


Check all missing work orders for the same problem and change the work centers.

We change the work centers for our two problem work orders – WO000119 and WO000120.

 

All work orders should now appear in Production Scheduler.

Other data issues

Some data issues can cause problems with site initialization. These can produce errors that are not obvious from the log.

  1. View the log in the Production Scheduler Manager.

    2. Our example has some errors.

    This message appears to be more helpful than the errors in the previous example.

    The log states that there is an X3 engine error: Date Error Incorrect().

    This would suggest there is a problem in the code.

  2. You can try the Postman application to identify problems.

    3. For our example we use Postman to check Sage X3.

    The result gives us the stack trace that details the line of code where the error occurs.

    This is a known problem.

  3. To find the work order causing the problem, follow the guidelines of removing all work orders and then adding them one by one.

    4. Our example has a problem with work order WO000126. All the operations are closed but the work order is still active.

    The workaround is to remove the work order from Production Scheduler. There is no more work to schedule as all of the operations are complete so this should not affect us, or we can close the work order.

You might need to remove the problem work order from Production Scheduler.

You could just close the work order.

This issue was resolved with V11 patch 7.
  1. View the log in the Production Scheduler Manager again.

    2. Our example has fixed the previous issue, however an issue remains:

  2. You can use Postman to give more details.

    3. Our example appears to be identical to the previous issue. Postman returns identical results.

    This gives us the stack trace that details the line of code where the error occurs.

    This is a known problem.

  3. To find the work order causing the problem, follow the guidelines of removing all work orders and then adding them one by one.

    4. For our example, work order WO000127 is causing the problem.

  4. Click the Scheduling action to view the scheduling information.

  5. Click the Graph action to view the graph.

  6. Now click the Show list icon to view the list of operations.

  7. Check the time the operation is due to end.

    8. This issue is caused by a difference between the capacity of the work center and the default capacity for the site.

    Our example has an operation which is due to end at 26:30 which when we try to convert to a date time, gives an error.

    This issue is caused by a difference between the capacity of the work center, in our example SEATTLE, and the default capacity for the site, in our example USA10 (8 hours).


The workaround is to ensure that the time schema associated with the weekly structure matches the capacity.

This issue was resolved with V11 patch 8.

Our example work center is SEATTLE. The weekly structure is SC6.

  1. We drill into the weekly structure.

  2. The daily capacity is 24 hours. However, there is no time schema specified.
  3. The default time schema STD specified in the DEFDIH - Default schedule parameter (GPA chapter, LOA group) is applied.
  4. The default time schema STD only has a capacity of 8 hours.

    This is why there is a problem with the calculation of the time.

  5. We specify a time table schema with the correct capacity.

  6. We add the time table schema to the weekly structure.

This resolves our issue.

 

All work orders should now appear in Production Scheduler.

Mapping problems

It is possible to have mapping problems that do not stop a work order being sent to Production Scheduler but does not transfer some of the data.

Our example work order WO000128 has a Forced start date.

The work order has been transferred to Production Scheduler.

The operation has been forced to a particular date.

The date, however, has not been transferred.

  1. Check the data sent to Production Scheduler. We use Postman to view the data from Sage X3.

    2. For our example we used a timestamp in the request to limit the data returned by Sage X3. In our example it is 02/07/2018 11:18:00.

    We can see that the operation is fixed, but there is no fixed date value.

You can convert a date and time into a timestamp using the following web page OnlineConversion.com.
  1. We use Postman again, but this time using api1 instead of the bundle.

    2. For our example we again use a timestamp (although using the format for Sage X3).

    We get the data back and can see that we do have a fixed date.

    There must, therefore, be a mapping problem, as Sage X3 is returning the correct information, but the bundle is not.

  2. Look at the mapping data for the POPSENVDET mapping code.

    3. Our example lists the FIXED value; the FIXDAT value is missing.

    This does not produce an error as it allows flexibility in the information returned by removing only mapping data, rather than changing the code or the representation.


Add the mapping data back.

  1. Resubmit the work order.

The fixed date is now being received by Production Scheduler.

There are no known issues of mapping data being incorrect. This information is provided as guide to establish issues which might occur.

Time zone not set / incorrect

Comparing details with the previous issue (Mapping problems), you might have a problem with the time zone.

Our example has an operation with a start date and time of 02/26/2018 09:00:00.

The work order scheduling information shows a start time of 08:00:00:

This is likely to be a problem with the time zone.

  1. The time zone is set in the PSTIMEZONE – Server time zone parameter (EXAPP chapter, MIS group) from a selection list.

    2. The time zone in the PSTIMEZONE – Server time zone parameter must be set to the server time zone.

Change the time zone to the time zone in which the server is located then resubmit the work order.

Our example has the time zone set to GMT Standard time. This is correct for our location.

However, the server that has Production Scheduler installed is located in France so we must change the time zone.

The time now matches the work order.

There is one known issue with the display of operations and time zones.

We know that in our example the start time of the operation is correct at 08:00:00, however, the operation appears to start at 07:00:00 in the Gantt chart. This is because the chart is rendered in the browser and uses the time zone of the browser, not the server.

This issue has been raised with 3DS, but it is noted to make you aware and avoid support calls.

Issues in the code

Comparing details with the Mapping problems issue again, you might have a problem with the time zone.

Our example is a new work order with a wait time of 3 hours.

The work order is in Production Scheduler:

The work order has no wait time.

In Production Scheduler, Wait time and Post-operation time are combined in Transit time after.
  1. As with the fixed date previously, you must determine why wait time is not being sent to Production Scheduler.
  2. Follow the same path and use Postman to determine where the error is.
  3. To restrict the returned data use a timestamp.
    1. To determine what the timestamp should be you can use the In columns function (GSTDCOL) (Development > Utilities > Maintenances > In columns) to check the update datetime on the work order.

      2. Set the column UPDDATIM to Display and set the Selection field to the work order.

    2. To return datetime information, select OK.

    4. Our example work order was updated at 09:42:01 on the 02/08/2018 (as returned by the In columns function (GSTDCOL)).

    We need a timestamp which is earlier than this datetime, so we could use 09:42:00 on the 02/08/2018.

  4. Convert the datetime for the bundle request into a timestamp.

    You can use a website to convert the datetime.

  5. You now have the timestamp to use as part of the key for the bundle request in Postman.

    6. Our example timestamp is 1518082920.

    We use this as part of the key for the bundle request in Postman.

    The data we receive has a timeOutResourceAfter as zero.

    This implies there could be a mapping problem.

  6. Check the output from Sage X3.

    7. For our example we set the timestamp to be a Sage X3 date time as in the In columns function (GSTDCOL).

    The output is returned.

    Our example also shows zero WAITIM. There is no mapping problem.

    If there was no WAITIM line in the output then it may be a missing value in the representation, but as we have the property WAITIM, albeit with a wrong value, there must be something in the code which is not outputting the wait time.
    In our example we have manually changed the code to not output the wait time, but there may be scenarios where there is an issue in the code which means incorrect information being sent to Production Scheduler.
    We change the code back to the original.


Correct the code then resubmit the work order.

The wait time (Transit time after) is updated correctly.

Troubleshooting 4: Data flow from Production Scheduler to Sage X3

Issues with data from Production Scheduler to Sage X3 are more difficult to analyse. They are not as easy to emulate as you cannot normally see the information that is being sent by Production Scheduler and the Production Scheduler logging provides minimal help as it normally only gives an http 500 error.

As an http 500 error does not give any indication of what the error might be you need to use the Sage X3 application logging, and in some cases Wireshark, to discover what the cause of the issue is. Some of the most common reasons are detailed below.

Work order data does not exist

Sometimes the published data in Production Scheduler is out of sync with Sage X3, therefore the publish is trying to update information that does not exist.

  1. If logging is enabled on the site, set the PSLOGTRACE - Production scheduler trace parameter (EXAPP chapter, MIS group) to Yes to see if there were any errors during the update process.
  2. Use the Log reading function (LECTRACE) (Reports > Reports > Log reading) to see the log files produced during an update:

  1. Open the last file and look at the final entries.
    2. Log files for the update process are prefixed POPSUPD followed by the site code, then the time.

    Remove the referenced work order and then try the publish again.

Our example is prefixed POPSUPD followed by site code USA10, then the time 12:23:04.

We open the last of these files – POPSUPD122304 – and look at the final entries.

This tells us that an operation could not be updated as a record was not found.

We would need to remove this work order and then try the publish again.

Work order locked (in use)

This is a very difficult issue to reproduce as it is not possible to change a work order whilst it is in Production Scheduler. However, as part of a production tracking the work order will be updated, so it could be locked at the point the Production Scheduler update is trying to access it.

This should only be a temporary situation and performing another publish should complete successfully.

For our example we follow the same process as the example above (Work order data does not exist) to look at the application log.

Again we are told that an operation could not be updated as a record was not found.

In the case of a locked record the message would explain that the record was locked.

We should be able to try the publish again, and hopefully the lock has been removed.

Invalid mapping

If information is not reaching Sage X3 after a publish in Production Scheduler you need to check the mapping against the output from Production Scheduler.

  1. Use Wireshark to retrieve the information being published by Production Scheduler.
  2. Check the values in the JSON against the mapping code POPSENVUPDEDIT in the JSON-X3 transformation mapping function.
  3. Match the invalid property in the output from Production Scheduler to the mapping value.

Correct the invalid property.

Our example starts with an extract of the output from Production Scheduler.

There is a comment, however, when this work order is updated in Production Scheduler the comment has disappeared. This must mean that somehow Sage X3 is not recording the comment.

We need to check the output against the mapping.

  1. We open the JSON-X3 transformation mapping function and select the POPSENVUPDEDIT mapping code.
    2. We need to understand the JSON class path. Each property has a parent class. In our example comment is part of the markers class, which is part of the operations class, which is part of the workOrders class.
    So the class path for comment is workOrders.operations.markers.
  2. We look at the mapping for the JSON class path.
  3. We see that there is no property comment, but there is one called comments.

    4. This mismatch is the cause of the problem.

    We change the mapping to comment.

 

We should begin to get the comments in Sage X3 and then sent back to Production Scheduler.

Problem in the code

Although all issues with publishing have been resolved, it is possible there may be a scenario that we have not envisaged that causes a problem in the code.

We find these issues by looking in the application log.

  1. Enable the application logging by setting the PSLOGTRACE – Production scheduler trace parameter (EXAPP chapter, MIS group) to Yes.

View the last log starting with POPSENVUPD to see if there were any errors during the update process.

Our developers need the information in the application log to resolve an issue.
  1. For our example we follow the same process as the example above (Work order data does not exist) to look at the application log.
  2. We view the last log starting with POPSENVUPD.

  3. The final entry is Operation update MFGNUM = WO000119.

  4. We look at the previous log file.

  5. The last entry is End of processing.

    This means that the update process did not complete successfully as we did not get the End of processing message in the previous log file.

This is likely to be a problem in the code as the process has not completed.

Time zone not set/incorrect

If work orders published from Production Scheduler to Sage X3 have operation start or end times that differ from Production Scheduler, the time zone parameter may not be set or may be incorrectly set.

Follow the procedure for Sage X3 to Production Scheduler Time zone not set / incorrect to correct the error.