Hello Friends,

I am invoking the service ‘wm.tn.doc.xml:routeXml’ from one of my flow services. I am passing content and contentType fields as input. But I am getting following error:

com.wm.app.b2b.server.ServiceException: Couldnt insert new document
(0) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-01401: inserted value too large for column
(1) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-01401: inserted value too large for column
at wm.tn.doc.persist(doc.java:789)
…
…
…
…

I am not sure why this error occurs ? I was succeeded previously with the same content.
I tried the same input passing to the wm.tn:receive service, but it also throws the same error.

Thanks in Advance.

Regards,
Nilesh

Same thing is happening to our system. Seems to be in all environments, DEV/QA/PROD. Just started happening today, same documents as we always send.

Same thing is happening here.

We are also facing the same issue on our Prod TN since 2:00 pm today.Assumed to be DB error. Seems like we have some greater issue.
Please keep posted if any updates.

Nilesh,

Have you tried recycling the IS/TN or reloading the TN related packages?

Also try to use small size xml document or create a new dummy document in TN and then push it to TN using ISAdminConsole/WmTNWeb document submission,if this works then try using routeXML service by just providing node as input.

HTH,
RMg.

What is you environment?
IS machine, Database, etc…

We are facing the same problem running on IBM AIX, Oracle 9.1.

Please, let me know if you find something…

Thanks

It seems that there is a GLOBAL webMethods ISSUE. Contact the wM Helpdesk.

Seems to be a column in BIZ_DOC that is too small.

Its weird everybody seeing same error?whats going on…let me check in our system too…

We just got off the phone with Tech Support. It’s a Global issue with TN creating a 25-byte Bizdoc Document ID and trying to insert it into a 24-byte field on the database. They’re working on a fix and will publish it as soon as they can.

Can everyone with this issue post your database and wM server versions? Maybe we can find a common thread. We’re on webMethods 6.1 and Oracle 9.2.0.3. We’re seeing the issue on both HP/UX and Windows 2000 servers.

RMG - we’ve tried all different types of documents and server restarts, nothing has worked yet.

Wow! We just started seeing that today as well in Dev/Test. I’m going to try not logging content in the Doctype settings until I can figure out what’s going on. But how weird that everyone’s seeing this at the same time. Do we have an embedded virus of some sort here?

Dave - thanks for posting that. I figured it was something like that from the errors, but couldn’t find any data to support the theory. Any idea how they discovered exactly where the problem was?

Michael - I doubt we’re talking about a virus. More likely webMethod simply used the date somehow in their algorithm for generating the bizdoc ID, and at a certain time that algorithm generated a larger number than they expected.

Thanks Dave for the update,

Skip,
Actually the same error is throwing in all 6.x versions.

Hello,
we are seeing the same problem. We are on WM601 on a sun 5.8 with oracle 8.17. Our sever has been working fine for month at a time, why all of a sudden today we would the same issue?
Regards,

Hello,
we are seeing the same problem. We are on WM601 on a sun 5.8 with oracle 8.17. Our sever has been working fine for month at a time, why all of a sudden today we would the same issue?
Regards,

Skip,

Yes I see, thanks. Jonathan, as Skip suggested, there’s undoubtedly some date/time-based component in the internal DocumentID that caused this string to just today become larger than the 24 bytes allocated to it in the Bizdoc table. Let’s keep an eye out for a Fix from support.

Thanks for the info. Hope to get the update soon.

Hello,

I think its really something wrong with the webMethods product itself.

RMG,
I tried sending small document and restarting server, re-enabling the TN packages, but nothing is working out.

I am using SunOS with WM 6.1

Keep posting if anyone gets some update.

Regards,
Nilesh

Nilesh,

Thanks for trying…

Anyways its a global issue now,WM is going to release a fix for this…somebody will definetely update…

Regards,

the last i called webMethods, there were atleast 35 other partners reporting this since about 2:45 PM EST.

ANyone using anything other than Oracle - we are on Oracle 9.2.04

thinkb2b,

The problem is seeing on SQL Server too…

Its the problem with the length defined for the field in table. So what ever the database it is, its going to error out.

We are going to resize our BIZDOC table’s DOCID field to be greater than 24 bytes.

We are going to resize our BIZDOC table’s DOCID field to be greater than 24 bytes.

we are going to try increasing column length in a Dev database and see.

ANyone have updates on when webM expects a fix?

from a colleague - “webM support says they hope to have a fix before 7:00 PM EST”

Hey Guys,

What is the table name in which webMethods stores the Document ID ?

Regards,
Nilesh

This is a wM bug. If you move one day back it works fine. WM will provide fix for it soon.

as per my esteemed colleague who is still on the phone with support - “webM support also says that db changes will not be necessary - looks like they are fixing the ID generation algorithm - as they should”

Yes, BIZDOC is 24 characters. WM has confirmed that you’re hitting 25 characters now.

Ask yourself this. Even if your solution to extend the field a few characters works, will your Business Users/ Project Managers let you put a non-vendor supported fix into production?
Not everyone can pass that test, you may want to wait on a vendor supported fix. CYA

Nilesh,

The table name is bizdoc, the column is document id.

I think the jar file would be updated to fix the bug

That’s very true. I am agree with RandyB1.

But if you are at development/testing stage, then I would suggest its better to modify the database column size and resume your development work instead of just waiting for the fix from Wm guys.

I am totally agree that client won’t support such a temporary solution in production which is not supported by the vendor.

• nilesh

any update from outside the USA???

as Fan mentions, it works if you move the date back - thats what webM says - ONLY to continue development. They are still working on the fix, and should have it soon.

Anyone aware of users in Europe/Asia - is it based on GMT or local time?

Word is that there will be a fix in the next 1/2 hour… or so. I’m unsure if that means a tested fix, or just a fix.
They are saying it will NOT be a DB fix, but an IS fix.

You might want to hold off on the db modifications

We have to stick and wait for the WM support fix,increasing the column size as a temporary fix is not a wise resolution…

I agree with Randy,

you are right, Randy - my curoisity was only to find a workaround - not that we would really put it in Production. We are actually making the change in our Dev environment - so some dependent applications can test. we will reverse it as soon as the fix is available…

Raghu,

Thanks for the information.

Regards,
Nilesh

How comfortable is everyone that the patch will not generate a key that violates the RI on the db? We have 1.5 million rows in Bizdoc.

Anyone hear if the fix from WM is available?

Let’s see…

import java.util.Date ;

public class test {
public static void main(String args) {
long t = 0x10000000000L ;
System.out.println("t = "+new Date(t)) ;
}
}

…

t = Wed Nov 03 13:53:47 CST 2004

Cheers,
++Yoni

By 5PM PST is what I got.

They initially said 4 PM PST - but obviously, thats not gonna happen

will post as soon as we hear

Latest I got was that emails would be sent to the Technical Contacts for each customer with the fix attached. Est. 7 - 8PM. So their pushing it. We’re not holding our breath.

Should be some interesting talks at Integration World.

Got this from wM:

*** webMethods Trading Networks Critical Error ***
Posted By: richard.augugliaro.6908

Valued webMethods Customers,

We have a critical situation that all of our Trading Networks users are
experiencing. This problem causes Trading Networks to stop processing all inbound documents. Our Product Development Team has isolated the root cause of the problem and will have a fix created and tested within the next one to two hours (between 7:00 and 8:00 PM US Eastern Time). We will notify you as soon as the patch is available and provide instructions for how to apply the fix.

We apologize sincerely for the significant effect that this situation is
causing our customers.

Richard Augugliaro
Vice President, Customer Care
714.915.8001

2 minutes… since they cost us in blood I thought I would count them off.

Anyone get the patch yet?

THIS IS THE MESSAGE POSTED ON THE ADVANTAGE WEBSITE

Valued Trading Network Customers,

We are aware of the difficulties you are currently experiencing with your inbound processing within Trading Network. We will have a patch to correct the problem to you within the next one to two hours (between 7:00 and 9:00 PM US Eastern Time).

You will be notified as soon as it becomes available, and be provided instructions for how to apply.

Our most sincere apologies to all of you for the inconvenience this has caused.

Our staff is available to support you with any questions you may have.

Worldwide Support:

North America: +1-888-222-8215 or +1 703 460 2584
Europe: +800 963 84-637 or +31 20 77 83 640
AsiaPacific: +1800 117 411 or 8913 1111

Australia: +1 800-088-880
China (Northern): 10800 610 0302
China (Southern): 10800 261 0302
Hong Kong: 800 933 819
India: 000 800 650 1184
Malaysia: 1800 807 806
New Zealand: 0800 330 669
Singapore: 800 6161 851
Thailand: 001 800 611 2851
Indonesia: 001803 61589
Philippines: 18001 611 0271
Korea: 00 308 610 062
Taiwan: 00 80611387
India: 000 800-650-1184
Japan: 00 531 610 062
Sri-lanka: 01 430 800

Richard Augugliaro
Vice President, Customer Care

at 7:50 PM EST, they said ‘20 more minutes’

thinkb2b - we are in Australia on the eastern seaboard. Problem was detected in our production environment at 2004-11-04 06:54:27 Australian Eastern Daylight Time.

This is GMT 2004-11-03 07:54pm previous day (wed), or
2004-11-03 14:54 previous day (wed) US ‘Eastern’ time.

We are running 6.0.2 on Oracle 8i on hpux.

cheers,

Al

Did anyone else hack the db?

still waiting
at 8:28 MTL time any one got news ?

Haven’t seen or heard anything from wM. When we do, what are the chances of actually getting the file though? I don’t have confidence in the bandwidth of their site, esp. when every customer attempts to download at once.

Any one got the patch, we have the same problem

I think allot of people are still dead in the water.

Jason Hanna,

If you are on the support ticket they will send e-mail attachment to you. Probably want to call support.

webMethods should email the zip file to the reported customer and call them personnally

Anyone have a line on the webMethods admins at Dell?

Alistair,
Thanks for the info - that matches up with my conviction that its not dependent on Time Zone (but all of us knew that already :-))

Jason,
I hope they do ALL OF
a) mass e-mail AND
b) Advantage download AND
c) FTP server

It is still the same .Anyone heard of any fix from webM tech support.

Anyone know what wM’s Service Level Agreement is? Even though the majority of our documents are recoverable, I can’t help to think we’re losing business over this.

Just received a patch for TN 6.0.1 by email…

there is plenty of time to pore over SLAs - this bug essentially shutdown our company - no small feat - and we aint that small either There is going to be some interesting converstations over the next week.

Just spoke with the WM rep, he was saying that they are going through the list and emailing the fix and readme file

The code that is causing all the problem… atleast on TN 6.1.

The link on advantage that explains the unique identifier format [url=“http://advantage.webmethods.com/article/?id=1611541961”]http://advantage.webmethods.com/article/?id=1611541961[/url]

package com.wm.app.tn.util;

import com.wm.util.Config;
import com.wm.util.Debug2;
import java.io.PrintStream;
import java.net.InetAddress;
import java.net.UnknownHostException;

public class IDMaker
{

public IDMaker() 
{ 
} 

public static synchronized String get() 
{ 
String time = toBase32String(System.currentTimeMillis()); 
String num = pad(4, toBase32String(nextId++)).toString(); 
StringBuffer tid = new StringBuffer(); 
tid.append(host).append(seq).append(time).append(num); 
if(nextId == 0x7fffffff) 
nextId = 0; 
return tid.toString(); 
} 

private static StringBuffer pad(int bytes, String s) 
{ 
int len = bytes * 2; 
int strlen = s.length(); 
if(strlen >= len) 
return new StringBuffer(s); 
StringBuffer sb = new StringBuffer(); 
for(int i = 0; i < len - strlen; i++) 
sb.append("0"); 

sb.append(s); 
return sb; 
} 

private static String toBase32String(long i) 
{ 
char buf[] = new char[64]; 
int charPos = 64; 
int shift = 5; 
int radix = 1 << shift; 
long mask = radix - 1; 
do 
{ 
buf[--charPos] = digits[(int)(i & mask)]; 
i >>>= shift; 
} while(i != 0L); 
return new String(buf, charPos, 64 - charPos); 
} 

public static void main(String args[]) 
throws Exception 
{ 
nextId = 0x7ffffffb; 
for(int i = 0; i < 12; i++) 
System.out.println(get() + "\n"); 

} 

static final char digits[] = { 
'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',  
'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j',  
'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't',  
'u', 'v', 'w', 'x', 'y', 'z' 
}; 
public static final int TRXJOB0001 = 1; 
public static final int TRXJOB0006 = 6; 
private static String self = "TXJobId"; 
private static int nextId; 
private static String host; 
private static String seq; 

static  
{ 
try 
{ 
host = toBase32String(Config.getLocalHost().hashCode()); 
int len = host.length(); 
if(len < 6) 
switch(len) 
{ 
case 5: // '\005' 
host = "0" + host; 
break; 

case 4: // '\004' 
host = "00" + host; 
break; 

case 3: // '\003' 
host = "000" + host; 
break; 

case

The fix has been emailed to us it is

The read me of the fix is

webMethods Trading Networks Server 6.0.1 Fix 39

                    November 2004 

This file provides important information for applying webMethods
Trading Networks Server 6.0.1 Fix 39 (TNS_6-0-1_Fix39) to webMethods
Trading Networks Server 6.0.1. For release information about
webMethods Trading Networks Server, see the Release Notes on the
webMethods Advantage Web site at http://advantage.webMethods.com.

Contents:

1.0 Fix Name
2.0 Product(s) Affected
3.0 Fix Requirements
4.0 Fix Contents
5.0 Platform Support
6.0 Installation
7.0 Cautions and Warnings
8.0 Globalization Statement
9.0 Copyright
10.0 Contacting Us

1.0 Fix Name

webMethods Trading Networks Server 6.0.1 Fix 39 (TNS_6-0-1_Fix39)

2.0 Product(s) Affected

This fix affects webMethods Trading Networks Server 6.0.1.

3.0 Fix Requirements

In development environments, a related Trading Networks Console
fix may be required. This fix is not required for production.

4.0 Fix Contents

This fix addresses the following issue:

1-THCUX
Inbound document processing stops because of invalid
document IDs.

Inbound document processing stops because Trading Networks
generates an invalid document ID. This causes the following error
to occur:

com.wm.app.b2b.server.ServiceException:
Couldnt insert new document.

This fix resolves the issue.

5.0 Platform Support

This fix is supported on all platforms that webMethods
Trading Networks Server 6.0.1 supports.

6.0 Installation

1. Shutdown the Integration Server.

2. Copy the file TNS_6-0-1_Fix39.jar into
   <integrationserver>/updates, where <integrationserver>
   is the location where you installed your server.

3. Update the properties.cnf file located in
   <integrationserver>\packages\WmTN\config by setting the
   following:

   tn.server.seq=31

   Note: If you have already defined this property, then change
   the current value to another value between 0 and 31.

4. Restart the Integration Server.

7.0 Cautions and Warnings

None.

8.0 Globalization

webMethods Trading Networks Server 6.0.1 Fix 39 (TNS_6-0-1_Fix39)
conforms to the internationalization standards of webMethods
and includes support for operation in any country, locale, or
language. Support for character encodings and proper
formatting, display, and validation of data (such as number
and date formats) has been provided throughout the webMethods
Trading Networks Server.

webMethods Trading Networks Server 6.0.1 is fully compliant with
the requirements of the Unicode Standard, version 2.1.8 (see
http://www.unicode.org). If you expect to display non-English
data in your webMethods tools, you need to ensure that an
appropriate font is installed in your operating environment.
You should test to see if there are hollow boxes or black
squares where you would expect to see non-English data, and if
you see problems, modify your JRE font.properties file to
reference the font on your system. Information on modifying
your font.properties file can be located on the Javasoft website
and in the FAQ at
<a href=“Display Problems” target=_

We did the DB level changes in our Dev and UAT and things are working fine but I am still waiting for WM to provide the fix and test it. Because to make changes in DB level will take more then 6 hours in our production.
We have more then 4 million rows in BizDoc table and 28 millions in activity log.

WM said that they will be sending the fix via email to every technical contact person who opened the issue.

we already got it - restarting our Dev environments right now - good luck everyone…

Did any one got for 4.6

What’s the cost of this to your business?

We did the DB level changes in our Dev and UAT and things are working fine but I am still waiting for WM to provide the fix and test it. Because to make changes in DB level will take more then 6 hours in our production.
We have more then 4 million rows in BizDoc table and 28 millions in activity log.

WM said that they will be sending the fix via email to every technical contact person who opened the issue.

4.6 had a bug and went back. ETA is 15 minutes to 45 minutes from now.

Please post any successes once the fix is applied. Indicate which version also…

THX!

The fix hasn’t been released for 4.6 yet. Anyone else running 4.6 got it?

Has anyone tried “Plan B” - shifting the server time one day?

If there is still a large delay to the 4.6 fix, we may try that option. We receive orders and send out order responses and invoices. Our order receipt process is tolerant to the time shift. But sending outbound documents with the timeshift may cause an error on partner systems. However, the outbound process isn’t as time critical as inbound for us.

Manish said:

>>Because to make changes in DB level will take more then 6 hours in >>our production.
>>We have more then 4 million rows in BizDoc table and 28 millions in >>activity log.

At what point did you add indexes so the full table scans don’t take you out?

TN 6.0.1 upgraded fix 39 (linux) in developement, test and production…
Production is the final test since other environments don’t have too much activity at this hour but everything looks great, no problems so far and all documents are processing normally…TN has been running for ~5mins now so not too much time to find anything but…thumbs up for now.

Cheers,
++Yoni

It works fine for me ,

Mine is 6.0.1 and it sits on oracle database 8.1.7

If you haven’t received the fix, go to advantage under “Fixes to Known Issues” then TN.

GL

We have installed TN 6.1 Fix 15 in production. Server was brought up and transactions are flowing through the system normally.

What is going on? how come this issue started so suddenly? is it a time based issue that occured due to some date or something? how come everyone having this issue suddenly

Hi Sonam,
Dont worry, this fix will work. webMethods is already released the fix which controls the generation of unique id to not to exceed 24 bytes, which is bascially class which generate uniqueid internally using some algoritham. By this everyone should be ok.
For going plan B, you have to do at BIOS level only, if you change the time at OS level, OS is smart enough to rollback to bois time settings. If we have to go to your plan B which is not at all possible for the people who has this problem in the production.

I guess best plan will be doing at DB level(increase column of BizDoc.DOCID to 25 from 24), that is only if webMethods is not able to provide the fix or fix doesn’t work. We tested Our plan B in Dev which works excellent.

Thanks “Paul Saker” pointing the right column, which saved a lot of our time.

Thnx,
SrujanGogineni

TN Fix39 working fine for IS6.01,

Thanks all,

Hi,

For us the problem was fixed with applying the patch.
TN version 6.0.1

Hi,

For us the same problem was fixed with the patch. We are on TN v6.1 using Oracle 8.1.7

Did anyone else notice the interesting comment in the Readme.txt stating the following?

3.0 Fix Requirements

In development environments, a related Trading Networks Console
fix may be required. This fix is not required for production.

I don’t know about any of you but for us the fix was required in ALL environments including Production.

Thinking their Legal Department was in on that paragraph.

Thanks Srujan.

We are running IS/TN 4.6. The fix for 4.6 was TNS Fix 86, which is working fine now for us in production with no errors.

In dev, we saw one failure in the first document submitted – a Java index out of bounds exception. But since the other tests after that ran fine, I’m putting it down to a one off effect of applying the patch.

We’re still waiting for the TN Console fix.

An interesting link on “time-shift testing”:
[url=“http://www-ssc.igpp.ucla.edu/~editor/vol05no083_1.txt”]http://www-ssc.igpp.ucla.edu/~editor/vol05no083_1.txt[/url]

After this incident, I fully expect WM to add time-shift testing to their regression test suite. It would be possible to run VMWare instances, programatically change the OS time, and run their tests.

For what it’s worth, I looked at what the fix actually does. It simply truncates the date part of the ID to 8 characters, keeping the most signifigant digits. Since this is base 32, and the date is 9 digits in base 32, you’re dropping one digit, which equates to 32 milliseconds. Therefore - instead of the date portion of the TN ID changing every millisecond, it changes every 32 milliseconds.

There is also a 4-digit sequence number, which equates to 1048576 (base 32, remember) available IDs for each date value. So as long as you receive less than 1048576 documents every 32 milliseconds, duplicates aren’t an issue.

I suppose in theory you might need to worry about what happens when the date goes to 10 digits, which would mean the date part would change only once per 1024 milliseconds, but that won’t happen until 3084-12-12 07:41:28.832. I’m guessing we’ll probably be using a different webMethods version by then.

All is well with 4.6 patch to this point.

If you have 6.1, you need to apply the TNC patch to any client PC that has TNC installed. It may appear to work without it, but (according to a wm support person) when you add or modify processing rules, it won’t work without the TNC 6.1 patch.

Roger,

Thanks for the information update.

Running the code that jogger007 posted, it can be determined that the problem first surfaced at:

11/3/2004 13:53:47

Sample output from the code is shown below:

11/3 13:53:46

ms: 1099511626805
time: vvvvvv1l
00000000vvvvvv1l00000007

11/3 13:53:47

ms: 1099511627838
time: 10000001u (9 characters now)
0000000010000001u00000007

To be more precise, the time of failure was 13:53:47.776.

date: 13:53:47.775
ms: 1099511627775
time: vvvvvvvv
00000000vvvvvvvv01vvvvvr

date: 13:53:47.776
ms: 1099511627776
time: 100000000
0000000010000000001vvvvvr

Third time’s a charm.

11/03/2004 19:53:47.776 GMT is the date when the Y2K-like problem occurred.

Details on the issue can also be found here:

[url=“http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?targChanId=tn_critical_issue”]http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?targChanId=tn_critical_issue[/url]

Some food for thought

We are operating IS and TN 4.6 on a Solaris 5.8 box with Sybase ASE 12.5. Our machine acts as an ebXML hub servicing a number of spokes. We were NOT affected by this problem in any way. Virtually all of our spokes who use webMethods were, with the exception of one, who uses a HP UX box and Oracle (don’t know versions)

We have applied the fix anyway and all still works fine.

Hi all,

Compliments for how this group has dealt with webMethods Y2k4 bug!

We finally get our fix from wM. However I am still wondering:

1. What is the meaning of tn.server.seq
2. How did you people manage SLA problems?

Best regards

Darren,
If your connection to database has SET ANSI FLAG setting “off” then it will work because this setting will truncate the values to their specified length of column in DB and ignore the error.

Cheers
MJ