Hi,

When my service tries to publish my 850 canonical document, it gets this error: pathName=/Order/OrderHeader/OrderIssueDate errorCode=DT-001 errorMessage=[ISC.0082.9447] Value does not conform to datatype.

I already changed the constent type to customermized and the pattern to mm/dd/yyyy ( which is actrual date format in pipepline) for the date. Did I do something wrong? I attached screen print for the document.
ContentType.doc (84 KB)

An XML Schema dateTime uses a pattern like "yyyy-MM-dd’T’hh:mm:ss.SSS’Z’, which does not appear to be what you want.

Suggest making this a simple string and not supplying a pattern until you understand things better.

Mark

If I want the content of the date to be validated, how could I do that?

Type the field as an xs:string (default) and supply a regular expression in the pattern field that will match your desired values.

This will cause any date field that does not match that regular expression to return the error that you are seeing now.

I would recommend against doing this until after you can successfully process these documents.

Mark

In the WM Deveoper, I change the content type constraint to “date_customized”. In the patten facet, I put /(…/…/…)/ which match mm/dd/yyyy. Why it still does not work? Our other process work fine and we are integrating them togather.

I would encourage you to drop the validation aspects within the integration layer altogether–especially in the publishable document. Detecting format errors within the integration layer is rife with issues that may or may not be easy to address there.

Here are the ways I deal with date-time fields, in order of preference:

1. Defined as string type, conforming to the W3C format (the format Mark described in his post). The first thing done for all interfaces when a doc comes in to IS is to normalize all date-time fields to this format. Validating for this is optional, and I usually prefer to turn it off.

2. Defined as Date type. All interfaces convert fields to a Date object. The interaction between IS and Broker automatically handles this type.

3. Defined as a string type, with no assumptions/work done to normalize date-time fields. The integration layer does nothing whatsoever to the data–just passes it through.

The key concept is to define a single internal format that is passed around IS and possibly to internal applications. When needed, convert to and from that format and the format needed by the specific interface (be it EDI, Siebel, SAP, Oracle, etc.) at the last possible moment in the integration.

If you really insist on doing validation at the field level with a custom date layout, try …/…/… I’m not sure you need the enclosing /( and )/ that you have in your example.

Side topic: What’s the rationale behind publishing an order?

I change the patten to …/…/… but still does not work, however when I change the content type from date_customize to string_customize with the same patten, it works. Does it mean I can not custmize the date content type?