Hi,
We have a service which uses the service dateTimeFormat.

The service is hardcoded with ddMMyy as Input format because the other system sending data to webMethods is sending it in this format and the we are converting it to MMddyyyy format.

Now, when we migrated that service to another region, the service is failing because the source system is sending the date in MMddyy format, while we have hardcoded the we will be getting date in ddMMyy format.

Whats are the possible options we have where without modifying to much of code and retest the service in both the environment we can recognize that the date on new system in coming in MMddyy format.

I am happy to modify the dateTimeFormat service but not the service we have written as it will require lot of testing on both envirnment

Assuming that the application in the new region is the same as the application in the old region, one option is to ask the application team to make both regions send the same date format.

That’s another option but not easy to implement as the user types the date and it will be difficult to ask each user to suddenly start typing date in this format, ofcourse there will be lots of type errors and application code change.

I see. The application should insulate your IS service from this. The application should always send you a date in a specific format, regardless of what the application lets its users do in the UI. Tying your integration to allowable values in a UI is a Bad Thing.

You note that the service hardcodes the format. you could have the value be looked up (e.g. use a config file). That way, your deployment in different regions could easily be changed to match whatever format is being used in that region.

Did this make sense?
-greg