BizTalk and Commerce Gateway

Fisherman
Fisherman Member Posts: 456
edited 2008-08-19 in Navision e-Commerce
All,

Does Commerce Gateway natively support integration with BizTalk through Microsoft Message Queue? I want to use MSMQ on our DMZ to act as a holding tank for information from an externally hosted BizTalk server, and have Commerce Gateway pick the messages off of the MSMQ. I need to know whether BizTalk and Commerce Gateway can communicate with MSMQ as the medium.

Thanks.

Comments

  • ara3n
    ara3n Member Posts: 9,258
    Not with Standard NAV.

    I'm sure you can build a custom solution, and I wonder why Navision decided to integrate a different way using

    CG Request server/client
    CG Brocker
    IIS



    CG Brocker is mainly for high volume, but it's still too many Setups, and many things that could go wrong and require many trouble shooting.


    I had hopped that with 2009 they would remove all the above solutions and provide a native solution through webservice (which comes by default), but I won't hold my breath.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Fisherman
    Fisherman Member Posts: 456
    That's disappointing. How can MS publish articles and whitepapers on the importance of a perimeter network with zero push from the public network, and then have its integration solutions set up as public facing with direct contact to your database?

    I guess we'll have to develop this on our own. I don't want public computers having access to our Domain, and the only solution I can see is to either use FTP to pull from our externally hosted BizTalk, or to use some holding area on our DMZ to hold information for processing.

    This is a definite let down.
  • DenSter
    DenSter Member Posts: 8,307
    Commerce Gateway is the integration between Biztalk and NAV, and it uses proprietary communication components, and the architecture was designed to have Biztalk run internally. Whatever comes into Biztalk from outside sources is up to you, so if you want to have an external app send messages into a message queue that Biztalk monitors, that could be one way of doing it, and it can be a very viable solution.

    In fact we once did an integration between NAV and MS CRM by using basic CG logic, and we wrote a component of our own that took the post callouts from CRM and sent those into a MSMQ that was consequently monitored by Biztalk, which in turn forwarded those messages through the Commerce Gateway components into the NAV database. No direct outside access to the NAV database.
    Daniel Rimmelzwaan
    RIS Plus, LLC
  • Fisherman
    Fisherman Member Posts: 456
    I guess that's true, so long as your process to deliver data to BizTalk was a pull and not a push.

    Even still - the documentation for the NAS installation shows an example that I would never think would be a good idea. On page 14, it shows BizTalk and IIS talking to the "cloud", with BizTalk directly connected to the NAV database.

    Can you tell me more about your custom solution? Was it difficult to write?

    What I'm interested in doing is having our externally hosted BizTalk server send XML messages to an MSMQ queue over HTTPS on our DMZ. That way, I can monitor the queue from inside the domain, pull in messages as they appear, and process them. I'm not sure if I really need Commerce Gateway at that point, or just a codeunit that can process the messages properly.
  • kriki
    kriki Member, Moderator Posts: 9,121
    [Topic moved from Navision forum to Navision e-Commerce forum]
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!

  • DenSter
    DenSter Member Posts: 8,307
    Fisherman wrote:
    I guess that's true, so long as your process to deliver data to BizTalk was a pull and not a push.
    I don't understand that comment. Are you suggesting that 'push' is 'good' and 'pull' is 'bad', or vice versa? Does it make a different whether something is a 'pull' or a 'push'? You 'push' messages into a message queue and you have Biztalk 'pull' them from there. Is that a problem? Does it have to be either one or the other to be able to call it a 'good' or a 'bad' solution?
    Fisherman wrote:
    Can you tell me more about your custom solution? Was it difficult to write?
    It was specific for our project, and it was about 6 years ago. We had an assignment to integrate MS CRM with NAV. We didn't want to write all of the communication, so we decided to use Commerce Gateway, mostly because the customer was already using Biztalk (something I would not do now by the way). We set up Biztalk to monitor a message queue and forward the messages through the NAV AIC. CRM though does not have a mechanism to send messages to MSMQ, at least not in that version, so we had to write a .NET component to catch the CRM post callouts and forward those to the MSMQ so that Biztalk could pick them up. It was a lot of work, but a lot of fun to do and it worked like a charm. I don't have access to the solution any more, because I don't work for that company anymore.
    Fisherman wrote:
    What I'm interested in doing is having our externally hosted BizTalk server send XML messages to an MSMQ queue over HTTPS on our DMZ. That way, I can monitor the queue from inside the domain, pull in messages as they appear, and process them. I'm not sure if I really need Commerce Gateway at that point, or just a codeunit that can process the messages properly.
    I'm not 100% sure how the latest version of Commerce Gateway works, there might be a good alternative in there for you. What does your NAV partner say about this? Investigating this would be a bit more work than I am willing to do for a forum like this :mrgreen:

    Developing a message queue monitor is fairly straightforward in C/AL, and you can use some of the existing Commerce Gateway logic as an example of how to process the incoming messages.
    Daniel Rimmelzwaan
    RIS Plus, LLC
  • Fisherman
    Fisherman Member Posts: 456
    I guess that's true, so long as your process to deliver data to BizTalk was a pull and not a push.

    I don't understand that comment. Are you suggesting that 'push' is 'good' and 'pull' is 'bad', or vice versa? Does it make a different whether something is a 'pull' or a 'push'? You 'push' messages into a message queue and you have Biztalk 'pull' them from there. Is that a problem? Does it have to be either one or the other to be able to call it a 'good' or a 'bad' solution?

    Sorry - I should have been more clear.

    If my BizTalk Server is inside my domain, I wouldn't want any external (internet/cloud) processes pushing data to that server. Instead, BizTalk should reach out and grab information, or some other process should reach out and grab the information and pass it off to BizTalk (like an EDI client/FTP, etc...).

    If BizTalk is on the DMZ/Perimeter, then it can be pushed to or can pull from the open internet, but shouldn't push to the domain. In that case, it should push to a queue/file-store on the DMZ which is pulled from the domain.

    MS's diagrams show the Cloud (internet) interacting directly with IIS/BizTalk which is talking directly to NAS/Commerce Gateway, which is really a horrible practice from a security standpoint.

    Our primary partner is really not well-versed in this area. We have another partner that we deal with, but I'm not sure of their expertise with BizTalk.

    I appreciate the info. Don't worry - I wouldn't ask anyone to research this kind of thing on a board (as a board moderator for a programming forum, I know how impossible that kind of thing is :)).
  • DenSter
    DenSter Member Posts: 8,307
    Thanks for the clarification, that does make sense. :mrgreen:

    I've also been surprised by the inconsistencies in recommendations/best practices from various product groups. What I assume is that some people are more/less risk-adverse and just don't agree that certain things are a security risk. It's just an assumption though, my wife calls it 'my usual BS' :mrgreen:
    Daniel Rimmelzwaan
    RIS Plus, LLC

Categories