Execute SQL stored procedure from BizTalk

问题:

I have three tasks to do in my BizTalk orchestration

1. execute a stored procedure with dynamic parameters
2. do a insert into DB
3. do a update in DB

Example data

stored procedure [databasename].[storedprocedurename] 'param1Value', 'param2Value'

table [databasename].[tablename] (id integer,desc nvarchar(50))

UPDATE

Rephrase: Tasks are

1. How to call stored procedure from BizTalk orchestration with parameters from incoming XML message

2. How to do insert into DB table from orchestration (and get back result of operation)

3. How to do update with dynamic "where' value conditions from incoming xml

回答1:

There is full documentation here: Executing Stored Procedures in SQL Server by Using BizTalk Server

High level overview:

1. Create your stored procedure (e.g. usp_Test) to do your inserts/updates. Include parameter(s) that would be used in your WHERE clause(s).
2. Use the Add->Add Generated Items->Consume Adapter Service to generate a schema and bindings file for the stored procedure.
3. Create a map from your message to the stored procedure schema
4. Update your Operation on the logical send port to match the SP name (usp_Test)
5. Deploy your Application.
6. Import the bindings for the physical send port from step 2 to your application
7. Bind the orchestration to this send port (or create a filter on the send port, perhaps based on BTS.Operation).
8. Create ports with the map set on the send port you've imported and a filter se the Orchestration).

BONUS:

9. Use table types to pass multiple inserts in a single call
10. Use CompositeOperations to call multiple procedures/tableops

CAVEATS:

• The SQL Adapter doesn't like empty nodes (assuming you're using SQL Server). Make sure a node that is supposed to go in as a NULL is either set to xsi:nil=true (use the Nil functoid), or that it's not present in the destination (use a Value Mapping functoid, or a method to remove empty nodes in a pipeline or helper class).
• Other adapters (Oracle or Db2 for example) will have their own particular challenges. IMO, the sqlBinding is the nicest to work with in terms of features available and documentation. If you know your other platform, you should be able to figure out the issues.
• Avoid sending XML parameters unless you intend to store the XML in SQL Server. In other words, don't make SQL Server shred XML when you have BizTalk to do that for you - BizTalk will almost certainly do a better job (performance and development wise).
• If you're returning data from SQL Server, consider using Strongly Typed (if your procedure result set is returned as a plain old SELECT or via OUTPUT parameters) or XML Polling (if your procedure returns a resultset using FOR XML). Avoid vanilla procedure calls unless you don't expect to deal with return data from the procedure.