1
0
-1

Hi,

we are about to embrace TM5 and the Fluent SDK, so I'm keen to make a good start and use best practices.

So, I was wondering about how best to structure my IDE projects - we are using IntelliJ IDEA.

I was planning to set up each service as a single project, rather than have multiple services in a project.

I'm wondering if this has any impact on deployment or development activities. Is there a recommend way to structure this, or is it a matter of me adopting my own best practices. Any feedback would be welcome.

 

Thanks

Mark

    CommentAdd your comment...

    2 answers

    1.  
      2
      1
      0

      Good question Mark, and great to hear that you are charging forth on the Fluent SDK!

      My advice would be to keep all related services in the same project. That is, all services related to the same task/function/capability (from a user's perspective) should be kept together. Think of the app-store concept where each app is a project that adds capabilities to your platform - some apps have a single function, others have multiple.

      For example, in the Avoka Exchange program we have a one project for each external system we integrate with (greenId, ESignLive). In each project we could have up to 5 or 6 services for sending and retrieving data between the systems. These may include dynamic data services, delivery services and scheduled services. The services can utilise common API code to save duplication and a developer making a change to a function has all the assets they need in one place.

      There are some considerations from a development perspective:

      1. Source control: In modern source control systems like GIT you configure developer access permissions at the project level, so consider how you want to lock down your projects.
      2. Common code: It is more cumbersome (but still achievable) to share common code between services in different projects.
      3. Overheads: There will be more maintenance with many projects (e.g. when a new SDK version is released with features you want, you'll have more projects to upgrade)

      I would not advocate having every service in its own project as a rule, nor would I recommend grouping services into projects based on their type (E.g Dynamic Data services in one project and Delivery services in another).

       

      1. Mark Murray

        Hi Ben, that's encouraging; I was thinking of the 'related services' concept as well - just trying to deal with how to implement it. I was thinking of putting GreenID in one project, Mastersoft in another and then put services for each form together - prefill, saved, completed, delivery. I'll consider some of your other points as well as I work through how best to architect our code base. Thanks fro the feedback. Mark

      2. Ben Warner

        Yes, that makes sense. Sometimes you need to develop a service targeting a specific form, although as much as practical you should design your services such that they are reusable across many forms. The use of service parameters to drive configuration options helps with this.

      CommentAdd your comment...
    2.  
      1
      0
      -1

      Hi Mark,

      Please see the documentation below:

      Avoka Transact Fluent SDK

      The Transact Project Template

      This has being used by the Avoka Exhange Team for developing their Fluent services, and is our current best practice.

      regards Malcolm

      1. Mark Murray

        Hi Malcolm, I have read that documentation and followed the examples to create a project template. It is working well at this stage. I have created a project and created a new service. So, I'm on the right track. I was looking at the next level up from a single project and wondering about the whole package of scripts/services for our overall application. Thanks for the feedback, it's all useful information. Mark

      CommentAdd your comment...