Forum Replies Created
-
Posts
-
Good question. You actually have a "Construct" with a "Message Assignment" inside which holds the sample code I had there before. The key is that no "regular" steps (maps, one message = another) are required, just simple setting of values.
To do that, do we have to keep any shape inside the construct shape – for eg message assignment shape or something like that.
Or is there provision to give assignments as in your previous message inside the construct shape itself.
I see. To do this. you'd do a "construct message" for the input, and simply set each parameter:
MyNewMsg.ID = "1234";
MyNewMsg.Name = "Richard";
And then send that msg to the service. No need for a map or anything to construct input for simple type(s).
That is clear. But how we can pass parameters to a web method if the method takes one or more simple types as parameters.
I have tried updating the date types in the xsd. But I still get the error back from the SQL Adapter "cannot convert type 'nvarchar' to money" or whatever the data type I am trying to conver to. When I look at what is happening using the SQL Profiler, all stored procedure parameters are sent as nvarchar.
If the return value is a simple value type, then you just get that back. If a complex value is returned, when you set up the web service (add –> web reference) BizTalk generates the schema representing the complex type. Then you just construct that message like any other (if the complex type is an input) or work with it as a message on the output.
Make sense?
Hi, Thanks for the reply.
I've some problems with the builtin adapter.
I've implemented BizTalk in a large bank company in **** but there are some problems:
1) Can you specify the polling interval?
The mainframe is beeing polled every 60 ms, that's way too much! If I look at the adapter, then see I a Property "Polling Interval" = 3 s but it changes nothing to current polling interval off 60ms. Correct me if I'm wrong, but the polling interval = checking every x seconds if there's a message in the queue in the mainframe.
2) BizTalk adapter acts strange
To receive messages, the adapter OPEN's a connection, does some GETs and CLOSE's the connection. Right? Mostely, this scenario works but what we see, is that the adapter does sometimes 10 x OPEN's then performs GET's and then 10 x CLOSE's.
I can always post some traces.
Is this behaviour normal?
Greetings
Try xs:decimal for money type
xs:String for Date in schema, and datetime rather than smalldatetime in procedure
hi sajid08,
thanks for your reply. actually i did look into the event log and found that there was an error in the schema…
thanks for the tip
Oops, first reply wouldn't work.
I have tested this one:
CarrierPINInfo —RecordCount —\
\—Interation———-\—–Equal —-\
\
CarrierPINNo—————————————————-\——–ValueMapping(Flattening) ——ouputThe xmlns="x-schema:phoenix.xapi" is not really a namespace. It is more like a processing instruction back from the day when XDR schemas were still used. It is instructing the parser to validate the document against an XDR schema called process.xapi.
The schema below will validate the document, but I am not sure of the runtime behaviour, this may fail in the XmlDisassembler.
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="XAPI">
<xs:complexType>
<xs:sequence>
<xs:element name="SERVICE_INFO">
<xs:complexType>
<xs:sequence>
<xs:element name="Id" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="USER_INFO">
<xs:complexType>
<xs:sequence>
<xs:element name="EmplId" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="INQUIRY">
<xs:complexType />
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>Michael,
As I can understand by your description, you want a queing mechanism to queue call messages to back office, they are currently sent using the web services, so there is no queuing.
BizTalk comes with two queuing adapters out-of-the-box, namely MSMQ and WebSphere MQ (MQ Series), so you can use one of these two no problem, if filenet supports them, on the other side of it you can make a web service call from BizTalk to your back office. The queing inside biztalk is database (Sql Server) driven as far as I know, so it is not the traditional queing system. So you need to decide on first how do you reach BizTalk first, would you prefer to use a queue to reach BizTalk or some other mechanism like SOAP, File etc. then once your messages is inside biztalk, it gives you the safety of database driven queing.
By putting BizTalk in b/w you'd get the benefit of assured delivery of messages even if the back office system is down, Centrallized management of all the calls etc.
Regards,
Sajid
If the orchestration is not shooted upon the arrival of message, there may be a problem with the subscription, have you re-checked the Receive shape of the orch. to see if it is set for receiving that type of message and is activated?
Is there any entry in the EventLog, when the message arrives?
Regards,
Sajid.
