I want to create an orchestration that allows a message to be received and for it to go through two different maps, one after the other. Which shapes would be required for this?
My idea was to use 'Parallel Actions' then have two 'Transform' shapes under each (With one having a 'Delay' shape so that this specific one follows), however reading up about 'Parallel Actions' seems to imply that the message will go to one path or the other, not send the same message to both direction.
How can I have the input message going through two BizTalk maps using Orchestration? What are the appropriate shapes to use?
You have two options:
Apply two maps sequentally with 2 Transform Shapes:
1) Source Message > Map1 > Destination Message 1
2) Source Message > Map2 > Destination Message 2
Send the Source Message to 2 different Send Ports, each one with one map configured.
If I understand your question correctly, you want to have two outbound maps. The input for your second map would be the output of your first map?
If so: you can just put two Transform shapes after each other. There is no need for a parallel actions shape.
Configure the Transform shapes to use the appropriate mapping and the mappings will be executed one after the other.
The other approach is to create a pipeline component capable of executing an XslCompiledTransform. Then, create a custom pipeline where both components are chained after each other and use that custom pipeline in your send port. Then you do not even need an orchestration (if no extra business logic is needed).
Up to you to make the correct decision, based on your specific needs.
Related
I created a simple schema on kicad (this one )
. Then I associated the corresponding footprint, generated the netlist file, then run pcbnew to create the PCB. But then I ended up with this mess and I don't know how to deal with it (I did draw the edge of the PCB ).
I am trying to draw a PCB that I can build myself with no crazy tool (so I guess single layer), but on this draw many line intersect with other line so not really what I was looking for a single layer PCB. Not sure it will help but all my kicad file are there kicad_file
The lines that you see are the connecting lines. In Diptrace it is called "ratlines". They obviously indicate where the connection is based on your schematic. Now on Diptrace there is an "AutoRoute" tool which will create routes (traces) based on the ratlines and it will try to do so a well as possible. I usually do the AUtoroute and if I am not happy with the result I do manual routing.
So I suggest you look for such a tool in your application. If it does not exist then don't be shy to create them yourself. Your PCB is not complicated so I am sure you will manage.
One thing to keep in mind though; If you find that traces will still intersect then there are two things you can do:
Use the space between the pins of the IC
Place pads where you can solder jumper wires.
Look at https://www.wayneandlayne.com/blog/2013/02/27/kicad-tutorial-using-the-autorouter/ for a post on autorouting
Normally seek commands are executed on a filter graph, get called on the renderers in the graph and calls are passed upstream by filters until a filter that can handle the seek does the actual seek operation.
Could an individual filter seek the upstream filters connected to one or more of its input pins in the same way without it affecting the downstream portion of the graph in unexpected ways? I wouldn't expect that there wouldn't be any graph state changes caused by calling IMediaSeeking.SetPositions upstream.
I'm assuming that all upstream filters are connected to the rest of the graph via this filter only.
Obviously the filter would need to be prepared to handle the resulting BeginFlush, EndFlush and NewSegment calls coming from upstream appropriately and distinguish samples that arrived before and after the seek operation. It would also need to set new sample times on its output samples so that the output samples had consistent sample presentation times. Any other issues?
It is perfectly feasible to do what you require. I used this approach to build video and audio mixer filters for a video editor. A full description of the code is available from the BBC White Papers 129 and 138 available from http://www.bbc.co.uk/rd
A rather ancient version of the code can be found on www.SourceForge.net if you search for AAFEditPack. The code is written in Delphi using DSPack to get access to the DirectShow headers. I did this because it makes it easier to handle com object lifetimes - by implementing smart pointers by default. It should be fairly straightforward to transfer the ideas to a C++ implementation if that is what you use.
The filters keep lists of the sub-graphs (a section of a graph but running in the same FilterGraph as the mixers). The filters implement a custom version of TBCPosPassThru which knows about the output pins of the sub-graph for each media clip. It handles passing on the seek commands to get each clip ready for replay when its point in the timeline is reached. The mixers handle the BeginFlush, EndFlush, NewSegment and EndOfStream calls for each sub-graph so they are kept happy. The editor uses only one FilterGraph that houses both video and audio graphs. Seeking commands are make by the graph on both the video and audio renderers and these commands are passed upstream to the mixers which implement them.
Sub-graphs that are not currently active are blocked by the mixer holding references to the samples they have delivered. This does not cause any problems for the FilterGraph because, as Roman R says, downstream filters only care about getting a consecutive stream of sample and do not know about what happens upstream.
Some key points you need to make sure of to avoid wasted debugging time are:
Your decoder filters need to be able to queue to the exact media frame or audio time. Not as easy to do as you might expect, especially with compressed formats such as mpeg2, which was designed for transmission and has no frame index in the files. If you do not do this, the filter may wait indefinitely to get a NewSegment call with the correct media times.
Your sub graphs need to present a NewSegment time equal to the value you asked for in your seek command before delivering samples. Some decoders may seek to the nearest key frame, which is a bit unhelpful and some are a bit arbitrary about the timings of their NewSegment and the following samples.
The start and stop times of each clip need to be within the duration of the file. Its probably not a good idea to police this in the DirectShow filter because you would probably want to construct a timeline without needing to run the filter first. I did this in the component that manages the FilterGraph.
If you want to add sections from the same source file consecutively in the timeline, and have effects that span the transition, you need to have two instances of the sub-graph for that file and if you have more than one transition for the same source file, your list needs to alternate the graphs for successive clips. This is because each sub graph should only play monotonically: calling lots of SetPosition calls would waste cpu cycles and would not work well with compressed files.
The filter's output pins define the entire seeking behaviour of the graph. The output sample time stamps (IMediaSample.SetTime) are implemented by the filter so you need to get them correct without any missing time stamps. and you can also set the MediaTime (IMediaSample.SetMediaTime) values if you like, although you have to be careful to get them correct or the graph may drop samples or stall.
Good luck with your development. If you need any more information please contact me through StackOverflow or DTSMedia.co.uk
I have flatfile at receive end & want to split it into multiple files of some fixed message size say 1000 messages per file. How we can implement it in receive pipeline?
I understand the scenario you are asking about.
The way to address this, given the Receive Port requirement, is with a custom Disassembler component that can manage the rebatching internally.
You can wrap FFDasmComp (that is the Flat File Disassembler) so it does most of the work.
There is no way to do this with out of the box tooling.
I have an orchestration called MyUsefulOrch, hosted in an application MySharedApp.
MyUsefulOrch has an inbound messagebox-direct-bound port to receive requests, and after doing some useful work, an outbound messagebox-direct-bound port to send a message to the caller.
Now, I have another orchestration called MyCallerOrch which wants to benefit from the useful processing provided by MyUsefulOrch. However, MyCallerOrch is hosted in a different application, MyCallingApp.
I do not want to have any references to the assembly which contains MyUsefulOrch from MyCallerOrch.
My problem now is making sure I can send a message to MyUsefulOrch from MyCallerOrch and receive a response from it.
Ahah! Correlation should do the trick! But how do I go about getting correlation to work in this scenario?
For example:
Would I put a correlation id in a property schema and stuff a guid into the message context under this property from MyCallerOrch just before sending it to the messagebox?
How do I ensure that MyCallerOrch receives only the responses it needs to receive from MyUsefulOrch?
Do I need to put the correlation id value into the message body of the messages which are sent between the two orchestrations?
I would greatly appreciate any help, ideally as descriptive as possible, about how to acheive this.
Many thanks in advance.
If you use a two-way, request/response send port in the caller orchestration to send messages to the useful orchestration, then you can use correlation to route the relevant messages back to the userful orch from the caller.
The trick is that you will need to modify the useful orch (to make it more useful, of course).
If you do not/cannot control whether or not callers to the userful orch are expecting a response back, then you would need to make the inbound (request) port a one-way port. The orchestration would then complete by sending to a one-way outbound (response) port.
To ensure that messages received from two-way/request-response callers are routed back properly, the construct shape of the outbound message inside your useful orch will need to set the following message properties to true using a message assignment shape:
BTS.RouteDirectToTP
BTS.IsRequestResponse
Before setting those two properties, though, also make sure to do something like msgOut(*) f= msgIn(*); in the same message assignment shape to ensure that other properties get copied over. If the inbound and outbound messages are not the same, then you have to manually set each of the required properties, one at a time.
Those properties, of course, in addition to the two above, are what help ensure that the result of the useful orch is properly routed to the caller. They should be inside your correlation set and are:
BTS.CorrelationToken
BTS.EpmRRCorrelationToken
BTS.IsRequestResponse
BTS.ReqRespTransmitPipelineID
BTS.RouteDirectToTP
I'm getting a bit ahead of myself, however, as you assign the correlation set to the outbound send shape only if BTS.EpmRRCorrelationToken exists msgIn. This is critical. I have used a decision shape in an orchcestration, with the decision based upon that exact phrase. If the result is true, then send the previously constructed message out and assign the correlation set from above as the Initializing correlation set. This will cause BizTalk to route the message back to the caller as its expected response.
If the result of the decision was false then the caller of the useful orchestration was one-way. You will still likely want to send out a result (and just have someone else subscribe to it). You can even use the same send port as for two-way responses, just do not assign the correlation set.
You will want to thoroughly test this, of course. It does work for me in the one scenario in which I have used it, but that doesn't absolve others from doing their due diligence.
I think you are pretty much on the right track
Since the 2 applications are going to send messages to eachother, if you use strongly typed schemas, both apps will need to know about the schemas.
In this case recommend that you separate the common schemas off into a separate assembly, and reference this from both your orchestration apps.
(Schemas registered on the Server must have unique XMLNS#ROOTs, even across multiple applications)
However, if you really can't stand even a shared schema assembly reference, you might need to resort to untyped messages.
Richard Seroter has an example here
His article also explains a technique for auto stamping a correlation GUID on the context properties.
Edit : Good point. It is possible to promote custom context properties on the message without a Pipeline - see the tricks here and here - this would suffice to send the context property to MyUsefulOrch and similarly, the Custom context could be promoted on the return message from within MyUsefulOrch (since MyUsefulOrch doesn't need any correlation). However I can't think how, on the return to MyCallingOrch that the custom context property can be used to continue the "following correlation", unless you add a new correlating property into the return message.
This is not a programming question per se. I am trying to build a system which consists of the following:
User calls system using regular land line
Some processing is done by asterisk
Call is forwarded to an external number (another landline/mobile phone)
Now I would like atleast 2 simultaneous lines on which the user can call. I would like to know the following:
Will the TDM410 work for what I am trying to achieve?
Since I want call forwarding, do I need an extra line for that? Or can I do it on the same line? e.g. for one user do I need one incoming line and one outgoing line or can I do both receiving and forwarding on the same line?
I have both asterisk books but am still unclear as to which card to purchase. Is the TDM410 with 4 FXO the right one? I am thinking of TDM410 because it has 4 lines so that I can use two for incoming and two for outgoing. Am I right? Can someone please point me to a link/online store?
Thank you very much for your time.
PS- I do not wish to use SIP. I want to use POTS for all my calls (incoming and outgoing)
The TDM400 with 4 FXO modules will work for what you need.
When you receive a call on one line, then that line is busy and you must use a different line to forward the call (Asterisk will bridge the calls but it needs 2 lines for that). You can buy them directly from Digium.
You need at least 3 landlines if you want to be able to receive calls from 2 lines; the third line will be the one you use to forward the calls, but only one call can be forwarded at at time and the other person will have to wait. If you don't want that then you need 4 landlines.