Biztalk - What do you call a 'difficult' application

Published Thu, Jun 15 2006 3:19 | William

I think I'm going back into one of my hypomanic phases b/c everything seems  so clear and I'm learning at an amazing pace.  Back to Biztalk.  Ok ok.  Back in the day I was pretty big into Biztalk.  For a while, it seemed like it was fizzling out and since we weren't using Biztalk at Tiba Solutions anymore [we basically rolled our own orchestrations which were pretty cool].  Ok, so I've been getting back into it with my time tested strategy... An hour a day for a month will get you everywhere.  No, I don't mean you can learn it in a month, heck, not much worth learning can really be done in a month, at least when it comes to technology.  But what I mean is, if you spend at least an hour, once a day, for a month (double up for days you miss and never miss more than two consecutive days, or three in a week), you'll be amazed with what you know.

Here's my four day report.

Schemas

I created some pretty complex schemas with complex types.  Simple types are for wussies.  Actually, they aren't but I was trying to sound cool.  Anyway, I'm comfortable with the schema editor and while determining which item to use is largely dependent on the app, and largely a judgement call, it's hard to know how well I know it.  However I think I'm pretty warm.

Message Mapping

This came too easy which makes me think I'm missing something big.  I"m not going to comment yet.

Functiods

How can any real geek have access to something named a functiod and not want to use it.  They almost sound like something you squeeze out and flush, but they are far from that. They rock.  My big problem is coming up with legitimate ideas for them.  I'm very inclined to learn stuff and create stuff just to be cool or see how it works.  Functiods are Manna from Heaven for people like me.

Process

Pretty straightforward here.  Nothing dramatic to report.

So basically, I can get pretty straightforwad orchestrations to work.

Deployment and Testing

Uhhh, yah, this is uhhh, umm, wow, I'm drawing a blank, oh yah, deployment, uh, yah, uh.  I'll have to get back on this one.

 

Ok, so here's what I want to know. A few of my friends like optionsScalper have worked with BTS.  What I want to know is "At what point do I know my game is strong?"  What sort of project would it have to be?  Number of schemas?  I doubt it.  Complexity of Schemas?  Probably, but just a piece of the puzzle.  Advanced Orchestration ?  THis has got to be where the men are separated from the boys.  So what makes you the man?  Calling diffefrent adapters?  That's not that hard so it must be more.  Writing your own?  Yah, that's got to be a sign of a real BTS developer.  Calling web services, WSE 3.0 etc in an orchestration?  That's got to be it.   What else, what else (leave out deployment b/c I just suck at that right now).

Anyone got any ideas?  What's a 'good' project to test yourself on to determine that you are ready for prime time?  I wanna be the Biztalk guru - as you may know, we breed Two Connect down there and I wanna rep Miami too.  Any fellow BTS students interested in collaborating on a project, please lemme know.

 

 

Comments

# Marc Jennings said on June 15, 2006 9:26 AM:

Lots of options for a "complex" project.  The most complex one I did was as follows :
1) Accept an XML message (schema was simple enough)
2) grab a manufacturer id from the context bag
3) stash the file in a WSS folder
4) Send the file to a manufacturer-specific map to create an (interim) output format.
5) Query SQL to get default data, and import into the interim document.
6) save the interim document to another WSS document library
7) wait for user input via InfoPath (using a new column in the doc lib)
8) take the edited data, check validity.  If it is valid, move on.  If not, reset the "edited" flag and send back to WSS
9) grab more SQL data based on user input
10) re map to manufacturer speciic output format (including RosettaNet and/or EDI 850 formats)
11) send the file (which is actually now a PO)
11a) update central finance system to say the order was sent
12) wait for a response
13) notify the user of the response code
14) update the financial package with response data
15) start over.

It seems pretty straightforward broken down like that, but I'd hate to be the guy that has taken over my old job after I left.  :S

# William said on June 15, 2006 10:48 AM:

Hey Marc - I appreciate your resonse. Do you have a blog ?

# Jason S. Burton said on June 15, 2006 4:09 PM:

Good post, Bill.  I haven't run across any BizTalk "Best Practices" yet.  Here's a tip, though - Gilles Zunino just released a BizTalk add-in for Reflector.  

http://blogs.msdn.com/gzunino/archive/2006/06/09/623391.aspx

--jb

# Marc Jennings said on June 16, 2006 11:07 AM:

Hi William / Bill,

I do indeed have a blog, and this time, I remembered to put a link in this comment entry form :).  I hope you can find some useful stuff on there, but it does tend to be fairly whimsical.

Marc.

# William said on June 16, 2006 11:42 PM:

Jason - WUZZZUP Homie - I'm in g'ville this weekend, gimme a holla.

Search

This Blog

Tags

Community

Archives

News

My other sites

Cool Stuff

Book Stuff

Security

ORM

Data Access

Funny Stuff

Compact Framework Stuff

Web Casts

My KnowledgeBase Articles

My MVP Profile

Design Patterns

Performance

Debugging

Remoting

My Fellow Authors

My Books

LINQ

Misc

Speech

Syndication

Email Notifications