问题
I have three tasks to do in my BizTalk orchestration
- execute a stored procedure with dynamic parameters
- do a insert into DB
- 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
How to call stored procedure from BizTalk orchestration with parameters from incoming XML message
How to do insert into DB table from orchestration (and get back result of operation)
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:
- 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). - Use the Add->Add Generated Items->Consume Adapter Service to generate a schema and bindings file for the stored procedure.
- Create a map from your message to the stored procedure schema
- Update your Operation on the logical send port to match the SP name (usp_Test)
- Deploy your Application.
- Import the bindings for the physical send port from step 2 to your application
- Bind the orchestration to this send port (or create a filter on the send port, perhaps based on
BTS.Operation
). - Create ports with the map set on the send port you've imported and a filter se the Orchestration).
BONUS:
- Use table types to pass multiple inserts in a single call
- 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 toxsi:nil=true
(use theNil
functoid), or that it's not present in the destination (use aValue 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 viaOUTPUT
parameters) or XML Polling (if your procedure returns a resultset usingFOR XML
). Avoid vanilla procedure calls unless you don't expect to deal with return data from the procedure.
来源:https://stackoverflow.com/questions/32970296/execute-sql-stored-procedure-from-biztalk