BizTalk - Delete without a schema

Question

• I am importing a file with 200+ records into a master table.
• The BizTalk package only services one source, other packages service other sources
• I am using strongly type stored procedures for all SQL CRUD
• All records inside the file come from the same source
• The file does not contain source name or source Id
• I want to determine source from package hard coded value
• The Master table contains records from several sources
• Before import: delete inside Master table existing records from source

• Unlike the file import, the delete statement happens once

  DELETE FROM Master WHERE SourceID = @SourceID

The file import works, but how can I hard code the delete source ID?

Answer 1

In your delete transform (just above the send shape) you can set up a SourcID property for the outgoing message. You can then populate the message context with this SourceID. This sourceID can then be used in your delete statement.

Answer 2

If I understand correctly, you want to delete all existing records for the SourceID before inserting new ones?

If so, you need to have access to the SourceID value on the inbound message into the orchestration.

To do this, use property promotion .

You can either do this:

1. inside a pipline component configured on the receive port so that the property is available when the message arrives on the orchestration, or,
2. inside the orchestration , which will require you moving the construct shape for the InsertCSV message above the delete construct shape, and promoting the property within the contruct shape.

Of these options, the first one is probably the best option as assigning properties should ideally be done during message dissasembly.

Alternatively, you can use an xpath() call within an Expression shape to interrogate the message using xpath, and retrieve the value like that. This way you can avoid thinking about property promotion.

However, while quicker to implement, this approach is not best practise because it makes your orchestration very sensitive to changes in message schema.