I am redeploying an old Biztalk 2010 project to a new Biztalk 2016 server. The code hasn't changed at all - as far as I can tell - so it should just be a straight deployment. I am very much a BizTalk newbie but I have managed to get it all set up. However, when I send a message it works through the orchestration until it gets to the point where it should call a stored proc - which it does - but it doesn't send the parameters. There is an audit step beforehand so I can see that it has generated the message with the values and the schema for the stored proc is there but I can't see why it isn't sending the values. Anyone have any idea why?
I have checked every setting against a live-running version and it all seems to be the same. I'm tearing my hair out and I have precious little to spare.
Related
As of yesterday, when I publish the (current) Product and its API, the deployed Assembly is not updated and what is running is from an earlier state - most likely from early December. The APIC domain was created at the end of Nov, so what I is deployed could even be the initial deployment.
As a test, I changed the API's description (add 'XXX') and changed a Gateway script to add XXX to a 'console.warn' at the start of the Assembly. The description change can be seen in Portal, but there is no 'XXX' visible in the DP log. I set DP log level to 'debug', but none of the 'tracing' statements added in Dec can be seen.
Does anyone have any ideas as to how I can resolve this? Or, how can I see the API's deployed code? I've looked in the DP File Management, but everything is dated at then end of Nov.
[EDIT]
Catalogs are in Dev mode, so I change and publish using same version. I have just done a series of tests using the api referred to above (VAT-Num-Check) (which is our first 'real' api) and an older trivial one that just divides two numbers. The Sandbox catalog is associated with the DEV gateway, and the SIT catalog, with the SIT gateway.
The other kind of corruption is, after deploying a new api, calling it results in 404 'No resources match requested URI'.
My conclusions are:
Something has broken in Mgmt server and/or DP APiC Gateway. Once code has been deployed to DP, it can't be changed or deleted. Changes in Portal are correct.
The possible exception is that the deployment of the VAT-Num-check API appears to have reverted to an earlier version after a CLI publish to the SIT Gateway this morning.
[/EDIT]
Background:
I have been creating a Windows script to publish draft Product/APIs and then run Postman tests. This means that I have been performing a lot of publish actions to DP (V5 type). On Monday evening, in my last run, the Postman tests all worked. Yesterday morning, some failed.
Back in early Dec, I made a change so that all JSON error messages in user responses used error as the 'prefix' to the message contents. Before that, some used message and some used reply. The reason for the failures is error messages have reverted to using the earlier 'prefix'.
API Connect 2018.3.7 went out of support on November 15, 2018. You'd need to upgrade to 2018.4.1.x, which will be supported for a longer term.
If you still have the issue at that point, then please open a support ticket for further investigation.
We have been seeing the following 'warnings' in the event log of our BizTalk
machine since upgrading to BTS 2006. They seem to occur
randomly 6 or 8 times per day.
Does anyone know what this means and what needs to be done to clear it up?
we have only one BizTalk server which is running on only one machine.
I am new to BizTalk, so I am unable to find how many tracking host instances running for BizTalk server. Also, can you please let me know that we can configure only one instance for one server/machine?
Source: BAM EventBus Service
Event: 5
Warning Details:
Execute batch error. Exception information: TDDS failed to batch execution
of streams. SQLServer: bizprod, Database: BizTalkDTADb.Cannot insert
duplicate key row in object 'dta_MessageFieldValues' with unique index
'IX_MessageFieldValues'.
The statement has been terminated..
I see you got a partial answer in your MSDN Post
go to BizTalk Admin Console ,check in Platform Settings -> Hosts, in the list of hosts on the right, confirm that only a single Host has the Tracking column marked as Yes.
As to your other question. Yes you can run a Single Host Instance on a Single Server. Although when your server starts to come under a bit of load you may want to consider setting up some more so you can balance the workload better.
I'm refactoring a very old reports generating function in an ORACLE web application. It used JavaScript to construct a URL, sending to the reports server to run a reports. What I want to do is processing it in the database, in PL/SQL procedures(invoked through mod_pl/SQL). I tried to use utl_http.begin_request to do that, but sometimes when the output file is large(PDF format, about 20 pages, 1.5M), I received an error:
ORA-29259: end-of-input reached.
The test codes for sending requests are quite simple:
--------upgraded 2013/08/27----------------------------------------------------------
UTL_HTTP.set_transfer_timeout(1000);
--some params setting....
myIdent := SRW.RUN_REPORT(myPlist); --here raise the exception(ORA-29273:request_failed; ORA-29259: end-of-input reached.) and procedure stoped.
r_stat := SRW.report_status(myIdent,myPlist);
#ThinkJet, Thanks for your help.
I logon the report server, found that the report still running after I got this exception in my program, and finally finished succefully.I tested for many times, and found everytime I got the exception just 5 minutes after I started request,no matter what kind of reports I was running and what size it was (sure, all big size,running for over 5mins).I'm wondering if it's something about configuration on oracle application server?
Does anyone have idea about this? Many Thanks.
ORA-29259 while SRW.RUN_REPORT
is ias 10g , this is cause by httpd.conf timeout parameter configuration
just
1.edit $ORACLE_HOME /Apache/Apache/conf/httpd.conf
change "Timeout" great than your report running time
2.restart http server and test it.
opmnctl restartproc ias-component=HTTP_Server
It take a time on Oracle Reports side to produce a big reports so a timeouts can occur sometime. Try to increase timeout with utl_http.set_ransfer_timeout procedure before originate a request and look if it helps.
After moving most of our BT-Applications from BizTalk 2009 to BizTalk 2010 environment, we began the work to remove old applications and unused host. In this process we ended up with a zombie host instance.
This has resulted in that the bts_CleanupDeadProcesses startet to fail with error “Executed as user: RH\sqladmin. Could not find stored procedure 'dbo.int_ProcessCleanup_ProcessLabusHost'. [SQLSTATE 42000] (Error 2812). The step failed.”
After looking at the CleanupDeatProcess process, I found the zombie host instance found in the BTMsgBox.ProcessHeartBeats table, with dtNextHeartbeatTime set to the time when the host was removed.
(I'm assuming that the Host Instance Processes don't exist in your services any longer, and that the SQL Agent job fails)
From looking at the source of the [dbo].[bts_CleanupDeadProcesses] job, it loops through the dbo.ProcessHeartbeats table with a cursor (btsProcessCurse, lol) looking for 'dead' hearbeats.
Each process instance has its own cleanup sproc int_ProcessCleanup_[HostName] and a sproc for the heartbeat watchdog to call, viz bts_ProcessHeartbeat_[HostName] (although FWR the SPROC calls it #ApplicationName), filtered by WHERE (s.dtNextHeartbeatTime < #dtCurrentTime).
It is thus tempting to just delete the record for your deleted / zombie host (or, if you aren't that brave, to simply update the Next dtNextHeartbeatTime on the heartbeat record for your dead host instance to sometime next century). Either way, the SQL agent job should skip the dead instances.
An alternative could be to try and re-create the Host and Instances with the same name through the Admin Console, just to delete them (properly) again. This might however cause additional problems as BizTalk won't be able to create the 2 SPROCs above because of the undeleted objects.
However, I wouldn't obviously do this on your prod environment until you've confirmed this works with a trial run first.
It looks like someone else got stuck with a similar situation here
And there is also a good dive into the details of how the heartbeat mechanism works by XiaoDong Zhu here
Have you tried BTSTerminator? That works for one-off cleanups.
http://www.microsoft.com/en-us/download/details.aspx?id=2846
I don't have any errors with my smart target application, but I do see in the event log, the following error messages:
ERROR 2012-09-19 14:30:09
com.tridion.smarttarget.utils.AmbientDataHelper - can't find defined
trigger-types in claim store (check if your smarttarget cartridge is
up and running)
and:
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out java.util.concurrent.TimeoutException at
java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) at
java.util.concurrent.FutureTask.get(Unknown Source) at
com.tridion.smarttarget.tags.TimeoutQueryRunner.executeQuery(TimeoutQueryRunner.java:64)
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out
I would really like to understand what is causing these and how I can remove them. Or some suggested steps to help me debug this would be great :)
As I say, everything is working perfectly, later on in the logs I see the query to ST is correct and the results being generated.
In the event that is helps, I'm running on a 2009 implementation with Smart Target 2010, java 1.5.
thanks
John
Sounds like you might have a trigger configured in ST that does not actually exist in the ADF (or is mismatched). Have you looked through your trigger-types.xml file for anything obvious? Have you disabled an ADF cartridge but not removed the corresponding trigger in the XML perhaps? See the documentation for Defining trigger types.
I think your timeout is coming from the SmartTarget region rather than FredHopper. Sometimes a query that isn't already cached in FredHopper can take a while to return, even though it's ultimately successful. The ST query tag has a timeout (defined in the smarttarget_conf.xml file, or over-ridden with a tag attribute) that it will wait for a response from Fredhopper for before resorting to using the fallback content. This might explain why you see later in the logs that the query is correct and that results are returned. See the documentation for <tcdl:query>.
No conclusive answer for you I'm afraid, but I hope that helps.
The first error is logged if your SmartTarget cartridge is not running -- or if the data that it puts into ADF is lost somehow (e.g. you have disabled sessions in your web server).
In that case, SmartTarget will still do a query but it won't include anything from the Ambient Data Framework in it. If you don't have any triggers based on ambient data, the end result is the same for you.
To get rid of the error, make sure that smarttarget_cartridge is configured correctly.
As for the timeout error, it simply means that the query sent to Fredhopper took longer than the configured time. In that case it will show the fallback content instead. If this is happening a lot, you might want to increase the timeout within smarttarget_conf.xml.
I hope you found the issue, but for future reference, the first error message is raised when the claim "taf:claim:ambientdata:definedtriggertypes" is not set by the SmartTarget cartridge. This can be caused by:
SmartTarget cartridge could not load the the trigger types from the SmartTarget server. The log will show an error "can't retrieve list of defined trigger types from FH".
The HTTP session on your web server is expired during an active visit (the HTTP session expired but the browser is still open) and the claim is "lost".
The server does not support sessions like Peter mentioned.